<feed xmlns='http://www.w3.org/2005/Atom'>
<title>glusterfs.git/tests/bugs, branch v6.5</title>
<subtitle>GlusterFS is a distributed file-system capable of scaling to several petabytes. It aggregates various storage bricks over Infiniband RDMA or TCP/IP interconnect into one large parallel network file system.</subtitle>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/'/>
<entry>
<title>glusterd: add GF_TRANSPORT_BOTH_TCP_RDMA in glusterd_get_gfproxy_client_volfile</title>
<updated>2019-07-16T04:56:14+00:00</updated>
<author>
<name>Atin Mukherjee</name>
<email>amukherj@redhat.com</email>
</author>
<published>2019-06-11T04:22:06+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=d06f676a3af0fc09074699ead25a4872d0a6020d'/>
<id>d06f676a3af0fc09074699ead25a4872d0a6020d</id>
<content type='text'>
... with out which volume creation fails with "volume create: &lt;xyz&gt;: failed:
Failed to create volume files"

&gt;Fixes: bz#1716812
&gt;Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
&gt;Signed-off-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;

Fixes: bz#1721105
Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
Signed-off-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
... with out which volume creation fails with "volume create: &lt;xyz&gt;: failed:
Failed to create volume files"

&gt;Fixes: bz#1716812
&gt;Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
&gt;Signed-off-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;

Fixes: bz#1721105
Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
Signed-off-by: Atin Mukherjee &lt;amukherj@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>features/shard: Fix block-count accounting upon truncate to lower size</title>
<updated>2019-07-03T11:16:10+00:00</updated>
<author>
<name>Krutika Dhananjay</name>
<email>kdhananj@redhat.com</email>
</author>
<published>2019-05-08T07:30:51+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=25e4a1249f3904a2a918194541566e3cda512c6b'/>
<id>25e4a1249f3904a2a918194541566e3cda512c6b</id>
<content type='text'>
Backport of:
&gt; BUG: bz#1705884
&gt; Change-Id: I9128a192e9bf8c3c3a959e96b7400879d03d7c53
&gt; Signed-off-by: Krutika Dhananjay &lt;kdhananj@redhat.com&gt;

The way delta_blocks is computed in shard is incorrect, when a file
is truncated to a lower size. The accounting only considers change
in size of the last of the truncated shards.

FIX:

Get the block-count of each shard just before an unlink at posix in
xdata.  Their summation plus the change in size of last shard
(from an actual truncate) is used to compute delta_blocks which is
used in the xattrop for size update.

Change-Id: I9128a192e9bf8c3c3a959e96b7400879d03d7c53
fixes: bz#1716871
Signed-off-by: Krutika Dhananjay &lt;kdhananj@redhat.com&gt;
(cherry picked from commit 400b66d568ad18fefcb59949d1f8368d487b9a80)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Backport of:
&gt; BUG: bz#1705884
&gt; Change-Id: I9128a192e9bf8c3c3a959e96b7400879d03d7c53
&gt; Signed-off-by: Krutika Dhananjay &lt;kdhananj@redhat.com&gt;

The way delta_blocks is computed in shard is incorrect, when a file
is truncated to a lower size. The accounting only considers change
in size of the last of the truncated shards.

FIX:

Get the block-count of each shard just before an unlink at posix in
xdata.  Their summation plus the change in size of last shard
(from an actual truncate) is used to compute delta_blocks which is
used in the xattrop for size update.

Change-Id: I9128a192e9bf8c3c3a959e96b7400879d03d7c53
fixes: bz#1716871
Signed-off-by: Krutika Dhananjay &lt;kdhananj@redhat.com&gt;
(cherry picked from commit 400b66d568ad18fefcb59949d1f8368d487b9a80)
</pre>
</div>
</content>
</entry>
<entry>
<title>tests/utils: Fix py2/py3 util python scripts</title>
<updated>2019-06-27T06:40:27+00:00</updated>
<author>
<name>Kotresh HR</name>
<email>khiremat@redhat.com</email>
</author>
<published>2019-06-06T07:24:04+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=5de46c74b281e6d0cf7168f8869bd179e7fff489'/>
<id>5de46c74b281e6d0cf7168f8869bd179e7fff489</id>
<content type='text'>
Following files are fixed.

tests/bugs/distribute/overlap.py
tests/utils/changelogparser.py
tests/utils/create-files.py
tests/utils/gfid-access.py
tests/utils/libcxattr.py

Backport of:
&gt; Change-Id: I3db857cc19e19163d368d913eaec1269fbc37140
&gt; BUG: 1193929
&gt; Signed-off-by: Kotresh HR &lt;khiremat@redhat.com&gt;

Change-Id: I3db857cc19e19163d368d913eaec1269fbc37140
updates: bz#1679998
Signed-off-by: Kotresh HR &lt;khiremat@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Following files are fixed.

tests/bugs/distribute/overlap.py
tests/utils/changelogparser.py
tests/utils/create-files.py
tests/utils/gfid-access.py
tests/utils/libcxattr.py

Backport of:
&gt; Change-Id: I3db857cc19e19163d368d913eaec1269fbc37140
&gt; BUG: 1193929
&gt; Signed-off-by: Kotresh HR &lt;khiremat@redhat.com&gt;

Change-Id: I3db857cc19e19163d368d913eaec1269fbc37140
updates: bz#1679998
Signed-off-by: Kotresh HR &lt;khiremat@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cluster/ec: honor contention notifications for partially acquired locks</title>
<updated>2019-06-03T04:08:06+00:00</updated>
<author>
<name>Xavi Hernandez</name>
<email>xhernandez@redhat.com</email>
</author>
<published>2019-05-09T09:07:18+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=7a387f97315f55e1c741d6ad749fb5621f067de0'/>
<id>7a387f97315f55e1c741d6ad749fb5621f067de0</id>
<content type='text'>
EC was ignoring lock contention notifications received while a lock was
being acquired. When a lock is partially acquired (some bricks have
granted the lock but some others not yet) we can receive notifications
from acquired bricks, which should be honored, since we may not receive
more notifications after that.

Since EC was ignoring them, once the lock was acquired, it was not
released until the eager-lock timeout, causing unnecessary delays on
other clients.

This fix takes into consideration the notifications received before
having completed the full lock acquisition. After that, the lock will
be releaed as soon as possible.

Backport of:
&gt; BUG: bz#1708156
&gt; Change-Id: I2a306dbdb29fb557dcab7788a258bd75d826cc12
&gt; Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;

Fixes: bz#1714172
Change-Id: I2a306dbdb29fb557dcab7788a258bd75d826cc12
Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
EC was ignoring lock contention notifications received while a lock was
being acquired. When a lock is partially acquired (some bricks have
granted the lock but some others not yet) we can receive notifications
from acquired bricks, which should be honored, since we may not receive
more notifications after that.

Since EC was ignoring them, once the lock was acquired, it was not
released until the eager-lock timeout, causing unnecessary delays on
other clients.

This fix takes into consideration the notifications received before
having completed the full lock acquisition. After that, the lock will
be releaed as soon as possible.

Backport of:
&gt; BUG: bz#1708156
&gt; Change-Id: I2a306dbdb29fb557dcab7788a258bd75d826cc12
&gt; Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;

Fixes: bz#1714172
Change-Id: I2a306dbdb29fb557dcab7788a258bd75d826cc12
Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>glusterd: define dumpops in the xlator_api of glusterd</title>
<updated>2019-05-08T13:57:24+00:00</updated>
<author>
<name>Sanju Rakonde</name>
<email>srakonde@redhat.com</email>
</author>
<published>2019-04-26T16:58:53+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=3fc7d08c1d5dd9ac9079ee60ea734342eafb42d0'/>
<id>3fc7d08c1d5dd9ac9079ee60ea734342eafb42d0</id>
<content type='text'>
Problem: statedump is not capturing information related to glusterd

Solution: statdump is not capturing glusterd info because
trav-&gt;dumpops is null in gf_proc_dump_single_xlator_info ()
where trav is glusterd xlator object. trav-&gt;dumpops is null
because we missed to define dumpops in xlator_api of glusterd.
defining dumpops in xlator_api of glusterd fixes the issue.

fixes: bz#1703759
Change-Id: If85429ecb1ef580aced8d5b88d09fc15258bfc4c
Signed-off-by: Sanju Rakonde &lt;srakonde@redhat.com&gt;
(cherry picked from commit 5d866c13efdcdeddf184f012aa88a652e90ff22e)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Problem: statedump is not capturing information related to glusterd

Solution: statdump is not capturing glusterd info because
trav-&gt;dumpops is null in gf_proc_dump_single_xlator_info ()
where trav is glusterd xlator object. trav-&gt;dumpops is null
because we missed to define dumpops in xlator_api of glusterd.
defining dumpops in xlator_api of glusterd fixes the issue.

fixes: bz#1703759
Change-Id: If85429ecb1ef580aced8d5b88d09fc15258bfc4c
Signed-off-by: Sanju Rakonde &lt;srakonde@redhat.com&gt;
(cherry picked from commit 5d866c13efdcdeddf184f012aa88a652e90ff22e)
</pre>
</div>
</content>
</entry>
<entry>
<title>extras/hooks: syntactical errors in SELinux hooks, scipt logic improved</title>
<updated>2019-05-08T13:56:20+00:00</updated>
<author>
<name>Milan Zink</name>
<email>mzink@redhat.com</email>
</author>
<published>2018-02-05T14:04:37+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=2aa9898720e3be2a203bec960103afc2558ddff6'/>
<id>2aa9898720e3be2a203bec960103afc2558ddff6</id>
<content type='text'>
Fixes: bz#1701818
Change-Id: Ia5fa1df81bbaec3a84653d136a331c76b457f42c
Signed-off-by: Milan Zink &lt;zeten30@gmail.com&gt;
(cherry picked from commit 1ad201a9fd6748d7ef49fb073fcfe8c6858d557d)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes: bz#1701818
Change-Id: Ia5fa1df81bbaec3a84653d136a331c76b457f42c
Signed-off-by: Milan Zink &lt;zeten30@gmail.com&gt;
(cherry picked from commit 1ad201a9fd6748d7ef49fb073fcfe8c6858d557d)
</pre>
</div>
</content>
</entry>
<entry>
<title>cluster/ec: fix fd reopen</title>
<updated>2019-05-08T13:54:59+00:00</updated>
<author>
<name>Pranith Kumar K</name>
<email>pkarampu@redhat.com</email>
</author>
<published>2019-04-16T08:49:47+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=bf69fa4727f2b4432d7d54312bc0177cbcf44936'/>
<id>bf69fa4727f2b4432d7d54312bc0177cbcf44936</id>
<content type='text'>
Currently EC tries to reopen fd's that have been opened while a brick
was down. This is done as part of regular write operations, just after
having acquired the locks, and it's sent as a sub-fop of the main write
fop.

There were two problems:

1. The reopen was attempted on all UP bricks, even if a previous lock
didn't succeed. This is incorrect because most probably the open will
fail.

2. If reopen is sent and fails, the error is propagated to the main
operation, causing it to fail when it shouldn't.

To fix this, we only attempt reopens on bricks where the current fop
owns a lock, and we prevent any error to be propagated to the main
fop.

To implement this behaviour an argument used to indicate the minimum
number of required answers has overloaded to also include some flags. To
make the change consistent, it has been necessary to rename the
argument, which means that a lot of files have been changed. However
there are no functional changes.

This change has also uncovered a problem in discard code, which didn't
correctely process requests of small sizes because no real discard fop
was being processed, only a write of 0's on some region. In this case
some fields of the fop remained uninitialized or with incorrect values.
To fix this, a new function has been created to simulate success on a
fop and it's used in the discard case.

Thanks to Pranith for providing a test script that has also detected an
issue in this patch. This patch includes a small modification of this
script to force data to be written into bricks before stopping them.

Backport of:
&gt; Change-Id: If272343873369186c2fb8f43c1d9c52c3ea304ec
&gt; BUG: bz#1699866
&gt; Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;

Change-Id: If272343873369186c2fb8f43c1d9c52c3ea304ec
Fixes: bz#1699917
Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently EC tries to reopen fd's that have been opened while a brick
was down. This is done as part of regular write operations, just after
having acquired the locks, and it's sent as a sub-fop of the main write
fop.

There were two problems:

1. The reopen was attempted on all UP bricks, even if a previous lock
didn't succeed. This is incorrect because most probably the open will
fail.

2. If reopen is sent and fails, the error is propagated to the main
operation, causing it to fail when it shouldn't.

To fix this, we only attempt reopens on bricks where the current fop
owns a lock, and we prevent any error to be propagated to the main
fop.

To implement this behaviour an argument used to indicate the minimum
number of required answers has overloaded to also include some flags. To
make the change consistent, it has been necessary to rename the
argument, which means that a lot of files have been changed. However
there are no functional changes.

This change has also uncovered a problem in discard code, which didn't
correctely process requests of small sizes because no real discard fop
was being processed, only a write of 0's on some region. In this case
some fields of the fop remained uninitialized or with incorrect values.
To fix this, a new function has been created to simulate success on a
fop and it's used in the discard case.

Thanks to Pranith for providing a test script that has also detected an
issue in this patch. This patch includes a small modification of this
script to force data to be written into bricks before stopping them.

Backport of:
&gt; Change-Id: If272343873369186c2fb8f43c1d9c52c3ea304ec
&gt; BUG: bz#1699866
&gt; Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;

Change-Id: If272343873369186c2fb8f43c1d9c52c3ea304ec
Fixes: bz#1699917
Signed-off-by: Xavi Hernandez &lt;xhernandez@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cluster/afr: Remove local from owners_list on failure of lock-acquisition</title>
<updated>2019-04-16T11:29:03+00:00</updated>
<author>
<name>Pranith Kumar K</name>
<email>pkarampu@redhat.com</email>
</author>
<published>2019-04-04T10:01:56+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=7ec3a8527f2fb341fc1f6e54ded36b157e4904fe'/>
<id>7ec3a8527f2fb341fc1f6e54ded36b157e4904fe</id>
<content type='text'>
When eager-lock lock acquisition fails because of say network failures, the
local is not being removed from owners_list, this leads to accumulation of
waiting frames and the application will hang because the waiting frames are
under the assumption that another transaction is in the process of acquiring
lock because owner-list is not empty. Handled this case as well in this patch.
Added asserts to make it easier to find these problems in future.

fixes bz#1699731
Change-Id: I3101393265e9827755725b1f2d94a93d8709e923
Signed-off-by: Pranith Kumar K &lt;pkarampu@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When eager-lock lock acquisition fails because of say network failures, the
local is not being removed from owners_list, this leads to accumulation of
waiting frames and the application will hang because the waiting frames are
under the assumption that another transaction is in the process of acquiring
lock because owner-list is not empty. Handled this case as well in this patch.
Added asserts to make it easier to find these problems in future.

fixes bz#1699731
Change-Id: I3101393265e9827755725b1f2d94a93d8709e923
Signed-off-by: Pranith Kumar K &lt;pkarampu@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>core: Log level changes do not effect on running client process</title>
<updated>2019-04-16T10:59:36+00:00</updated>
<author>
<name>Mohit Agrawal</name>
<email>moagrawal@redhat.com</email>
</author>
<published>2019-04-15T05:04:34+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=d2de3f66393d4f737e21eedab4200563a60f8bcc'/>
<id>d2de3f66393d4f737e21eedab4200563a60f8bcc</id>
<content type='text'>
Problem: commit c34e4161f3cb6539ec83a9020f3d27eb4759a975 set log-level
         per xlator during reconfigure only for a brick process not for
         the client process.

Solution: 1) Change per xlator log-level only if brick_mux is enabled.To make sure
             about brick multiplex introudce a flag brick_mux at ctx-&gt;cmd_args.

Note: There are two other changes done with this patch
      1) Ignore client-log-level option to attach a brick with
         already running brick if brick_mux is enabled
      2) Add a log to print pid of the running process to make easier
         debugging

&gt; Change-Id: I39e85de778e150d0685cd9a79425ce8b4783f9c9
&gt; Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
&gt; Fixes: bz#1696046
&gt; (Cherry picked from commit 798aadbe51a9a02dd98a0f861cc239ecf7c8ed57)
&gt; (Reviewed on upstream link https://review.gluster.org/#/c/glusterfs/+/22495/)

Change-Id: If91682830f894ab8f6857f19dcb1797fc15ca64c
Fixes: bz#1699715
Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Problem: commit c34e4161f3cb6539ec83a9020f3d27eb4759a975 set log-level
         per xlator during reconfigure only for a brick process not for
         the client process.

Solution: 1) Change per xlator log-level only if brick_mux is enabled.To make sure
             about brick multiplex introudce a flag brick_mux at ctx-&gt;cmd_args.

Note: There are two other changes done with this patch
      1) Ignore client-log-level option to attach a brick with
         already running brick if brick_mux is enabled
      2) Add a log to print pid of the running process to make easier
         debugging

&gt; Change-Id: I39e85de778e150d0685cd9a79425ce8b4783f9c9
&gt; Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
&gt; Fixes: bz#1696046
&gt; (Cherry picked from commit 798aadbe51a9a02dd98a0f861cc239ecf7c8ed57)
&gt; (Reviewed on upstream link https://review.gluster.org/#/c/glusterfs/+/22495/)

Change-Id: If91682830f894ab8f6857f19dcb1797fc15ca64c
Fixes: bz#1699715
Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>core: Brick is not able to detach successfully in brick_mux environment</title>
<updated>2019-04-16T10:55:51+00:00</updated>
<author>
<name>Mohit Agrawal</name>
<email>moagrawal@redhat.com</email>
</author>
<published>2019-04-11T15:08:53+00:00</published>
<link rel='alternate' type='text/html' href='https://fedorapeople.org/cgit/anoopcs/public_git/glusterfs.git/commit/?id=88ecd64604ce01c5bc2c2ca88e33b8dcf57d5ee8'/>
<id>88ecd64604ce01c5bc2c2ca88e33b8dcf57d5ee8</id>
<content type='text'>
Problem: In brick_mux environment, while volumes are stopped in a
         loop bricks are not detached successfully. Brick's are not
         detached because xprtrefcnt has not become 0 for detached brick.
         At the time of initiating brick detach process server_notify
         saves xprtrefcnt on detach brick and once counter has become
         0 then server_rpc_notify spawn a server_graph_janitor_threads
         for cleanup brick resources.xprtrefcnt has not become 0 because
         socket framework is not working due to assigning 0 as a fd for socket.
         In commit dc25d2c1eeace91669052e3cecc083896e7329b2
         there was a change in changelog fini to close htime_fd if htime_fd is not
         negative, by default htime_fd is 0 so it close 0 also.

Solution: Initialize htime_fd to -1 after just allocate changelog_priv
          by GF_CALLOC

&gt; Fixes: bz#1699025
&gt; Change-Id: I5f7ca62a0eb1c0510c3e9b880d6ab8af8d736a25
&gt; Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
&gt; (cherry picked from commit b777d83001d8006420b6c7d2d88fe68950aa7e00)

Change-Id: I7a2b6fc2d36405d51990376333e093661be48475
Fixes: bz#1699714
Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Problem: In brick_mux environment, while volumes are stopped in a
         loop bricks are not detached successfully. Brick's are not
         detached because xprtrefcnt has not become 0 for detached brick.
         At the time of initiating brick detach process server_notify
         saves xprtrefcnt on detach brick and once counter has become
         0 then server_rpc_notify spawn a server_graph_janitor_threads
         for cleanup brick resources.xprtrefcnt has not become 0 because
         socket framework is not working due to assigning 0 as a fd for socket.
         In commit dc25d2c1eeace91669052e3cecc083896e7329b2
         there was a change in changelog fini to close htime_fd if htime_fd is not
         negative, by default htime_fd is 0 so it close 0 also.

Solution: Initialize htime_fd to -1 after just allocate changelog_priv
          by GF_CALLOC

&gt; Fixes: bz#1699025
&gt; Change-Id: I5f7ca62a0eb1c0510c3e9b880d6ab8af8d736a25
&gt; Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
&gt; (cherry picked from commit b777d83001d8006420b6c7d2d88fe68950aa7e00)

Change-Id: I7a2b6fc2d36405d51990376333e093661be48475
Fixes: bz#1699714
Signed-off-by: Mohit Agrawal &lt;moagrawal@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
