<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:35:59 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[OVSDB-285] bridge not created if it&apos;s configured northbound while ovs node is disconnected</title>
                <link>https://jira.opendaylight.org/browse/OVSDB-285</link>
                <project id="10158" key="OVSDB">ovsdb</project>
                    <description>&lt;p&gt;If the connection between the plugin and ovs node is not active when a &lt;br/&gt;
configuration is requested via northbound rest api, that configuration will&lt;br/&gt;
not be made to the ovs node when it reconnects.&lt;/p&gt;

&lt;p&gt;to recreate:&lt;/p&gt;

&lt;p&gt;1.  connect ovs to controller&lt;br/&gt;
    sudo ovs-vsctl set-manager tcp:${IP}:6640&lt;/p&gt;

&lt;p&gt;2.  create connection in config store to match that as seen in&lt;br/&gt;
    operational.&lt;/p&gt;

&lt;p&gt;3.  create a bridge in config store and verify it&apos;s there in operational&lt;br/&gt;
    and on ovs node&lt;/p&gt;

&lt;p&gt;4.  disconnect ovs node (iptables can be used to block traffic OUT on &lt;br/&gt;
    port 6640, or just a reboot of ovs node)&lt;/p&gt;

&lt;p&gt;5.  while disconnected, create a new bridge in config store&lt;/p&gt;

&lt;p&gt;6.  reconnect ovs node and the configuration from 3 will still be there&lt;br/&gt;
    in operational as well as on ovs node, but the config made in 5 will&lt;br/&gt;
    not.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="21977">OVSDB-285</key>
            <summary>bridge not created if it&apos;s configured northbound while ovs node is disconnected</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10000">Done</resolution>
                                        <assignee username="vinh.nguyen@hcl.com">Vinh Nguyen</assignee>
                                    <reporter username="jluhrsen">Jamo Luhrsen</reporter>
                        <labels>
                    </labels>
                <created>Tue, 2 Feb 2016 01:40:23 +0000</created>
                <updated>Mon, 23 May 2016 17:53:34 +0000</updated>
                            <resolved>Mon, 23 May 2016 17:53:34 +0000</resolved>
                                    <version>unspecified</version>
                                                    <component>Southbound.Open_vSwitch</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                                                                <comments>
                            <comment id="41221" author="jluhrsen" created="Tue, 2 Feb 2016 01:41:29 +0000"  >&lt;p&gt;email thread for more on the conversation:&lt;br/&gt;
&lt;a href=&quot;https://lists.opendaylight.org/pipermail/ovsdb-dev/2016-February/002528.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://lists.opendaylight.org/pipermail/ovsdb-dev/2016-February/002528.html&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="41222" author="vinh.nguyen@hcl.com" created="Fri, 8 Apr 2016 23:08:01 +0000"  >&lt;p&gt;Code review submitted:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="41223" author="jluhrsen" created="Tue, 12 Apr 2016 17:37:29 +0000"  >&lt;p&gt;(In reply to Vinh Nguyen from comment #2)&lt;br/&gt;
&amp;gt; Code review submitted:&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Vinh,&lt;/p&gt;

&lt;p&gt;I tried to test this patch, but saw the same behavior of this bug.&lt;/p&gt;

&lt;p&gt;However, I had some trouble building the patch to create a distribution.&lt;br/&gt;
I was using our multipatch job in the sandbox, which will create an&lt;br/&gt;
entire distribution based on any patches.  I used this patch for that&lt;br/&gt;
job, but it failed when building with master (Boron).  The failure was&lt;br/&gt;
in yangtools (warning message below) so probably nothing wrong with the patch.&lt;br/&gt;
But pulling this patch in to the stable/beryllium branch I got a distribution&lt;br/&gt;
to build.  Using that distribution, I re-tested this bug and saw the &lt;br/&gt;
same behavior.&lt;/p&gt;

&lt;p&gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;WARNING&amp;#93;&lt;/span&gt; Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy: org/opendaylight/yangtools/yang2sources/plugin/YangToSourcesMojo : Unsupported major.minor version 52.0&lt;/p&gt;</comment>
                            <comment id="41224" author="vinh.nguyen@hcl.com" created="Tue, 12 Apr 2016 23:33:41 +0000"  >&lt;p&gt;(In reply to Jamo Luhrsen from comment #3)&lt;br/&gt;
&amp;gt; (In reply to Vinh Nguyen from comment #2)&lt;br/&gt;
&amp;gt; &amp;gt; Code review submitted:&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I tried to test this patch, but saw the same behavior of this bug.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; However, I had some trouble building the patch to create a distribution.&lt;br/&gt;
&amp;gt; I was using our multipatch job in the sandbox, which will create an&lt;br/&gt;
&amp;gt; entire distribution based on any patches.  I used this patch for that&lt;br/&gt;
&amp;gt; job, but it failed when building with master (Boron).  The failure was&lt;br/&gt;
&amp;gt; in yangtools (warning message below) so probably nothing wrong with the&lt;br/&gt;
&amp;gt; patch.&lt;br/&gt;
&amp;gt; But pulling this patch in to the stable/beryllium branch I got a distribution&lt;br/&gt;
&amp;gt; to build.  Using that distribution, I re-tested this bug and saw the &lt;br/&gt;
&amp;gt; same behavior.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;WARNING&amp;#93;&lt;/span&gt; Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy:&lt;br/&gt;
&amp;gt; org/opendaylight/yangtools/yang2sources/plugin/YangToSourcesMojo :&lt;br/&gt;
&amp;gt; Unsupported major.minor version 52.0&lt;/p&gt;


&lt;p&gt;Hi Jamo,&lt;/p&gt;

&lt;p&gt;I was able to verify the bug on the stable/beryllium branch. There are the  reproduction steps, please let me know if I missed something:&lt;/p&gt;


&lt;p&gt;1) git checkout stable/beryllium&lt;br/&gt;
2) chery-pick the patch: &lt;br/&gt;
   git fetch &lt;a href=&quot;https://git.opendaylight.org/gerrit/ovsdb&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/ovsdb&lt;/a&gt; refs/changes/58/37358/1 &amp;amp;&amp;amp; git cherry-pick FETCH_HEAD&lt;br/&gt;
3) build and run karaf&lt;/p&gt;

&lt;p&gt;4) connect an ovs node to controller&lt;br/&gt;
   sudo ovs-vsctl set-manager tcp:${IP}:6640&lt;/p&gt;

&lt;p&gt;5) create a bridge in config store and verify it&apos;s there in operational&lt;br/&gt;
    and on ovs node&lt;/p&gt;

&lt;p&gt;6) reboot the ovs node&lt;/p&gt;

&lt;p&gt;7) while ovs node disconnected, create a new bridge in config store&lt;/p&gt;

&lt;p&gt;8) when the ovs comes back up, verify that the bridge created in 5 and 7 are present in the operational as well as on ovs node.&lt;/p&gt;

&lt;p&gt;Thanks, Vinh&lt;/p&gt;</comment>
                            <comment id="41225" author="jluhrsen" created="Tue, 12 Apr 2016 23:44:22 +0000"  >&lt;p&gt;(In reply to Vinh Nguyen from comment #4)&lt;br/&gt;
&amp;gt; (In reply to Jamo Luhrsen from comment #3)&lt;br/&gt;
&amp;gt; &amp;gt; (In reply to Vinh Nguyen from comment #2)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Code review submitted:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; I tried to test this patch, but saw the same behavior of this bug.&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; However, I had some trouble building the patch to create a distribution.&lt;br/&gt;
&amp;gt; &amp;gt; I was using our multipatch job in the sandbox, which will create an&lt;br/&gt;
&amp;gt; &amp;gt; entire distribution based on any patches.  I used this patch for that&lt;br/&gt;
&amp;gt; &amp;gt; job, but it failed when building with master (Boron).  The failure was&lt;br/&gt;
&amp;gt; &amp;gt; in yangtools (warning message below) so probably nothing wrong with the&lt;br/&gt;
&amp;gt; &amp;gt; patch.&lt;br/&gt;
&amp;gt; &amp;gt; But pulling this patch in to the stable/beryllium branch I got a distribution&lt;br/&gt;
&amp;gt; &amp;gt; to build.  Using that distribution, I re-tested this bug and saw the &lt;br/&gt;
&amp;gt; &amp;gt; same behavior.&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;WARNING&amp;#93;&lt;/span&gt; Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy:&lt;br/&gt;
&amp;gt; &amp;gt; org/opendaylight/yangtools/yang2sources/plugin/YangToSourcesMojo :&lt;br/&gt;
&amp;gt; &amp;gt; Unsupported major.minor version 52.0&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Hi Jamo,&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I was able to verify the bug on the stable/beryllium branch. There are the &lt;br/&gt;
&amp;gt; reproduction steps, please let me know if I missed something:&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; 1) git checkout stable/beryllium&lt;br/&gt;
&amp;gt; 2) chery-pick the patch: &lt;br/&gt;
&amp;gt;    git fetch &lt;a href=&quot;https://git.opendaylight.org/gerrit/ovsdb&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/ovsdb&lt;/a&gt;&lt;br/&gt;
&amp;gt; refs/changes/58/37358/1 &amp;amp;&amp;amp; git cherry-pick FETCH_HEAD&lt;br/&gt;
&amp;gt; 3) build and run karaf&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; 4) connect an ovs node to controller&lt;br/&gt;
&amp;gt;    sudo ovs-vsctl set-manager tcp:${IP}:6640&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; 5) create a bridge in config store and verify it&apos;s there in operational&lt;br/&gt;
&amp;gt;     and on ovs node&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; 6) reboot the ovs node&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; 7) while ovs node disconnected, create a new bridge in config store&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; 8) when the ovs comes back up, verify that the bridge created in 5 and 7 are&lt;br/&gt;
&amp;gt; present in the operational as well as on ovs node.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Thanks, Vinh&lt;/p&gt;

&lt;p&gt;Vinh,&lt;/p&gt;

&lt;p&gt;I can try again using your steps 1-3.  Could you try again as well, and&lt;br/&gt;
instead of doing your step 6, can you run this command on your ovs node:&lt;/p&gt;

&lt;p&gt;  iptables -A OUTPUT -p tcp --dport 6640 -j DROP&quot;&lt;/p&gt;

&lt;p&gt;that will simulate the ovs node &quot;going away&quot;.  While it&apos;s in that state,&lt;br/&gt;
ovs-vsctl should show it&apos;s not connected.  Now, you can go back to your&lt;br/&gt;
step 7 and 8.&lt;/p&gt;

&lt;p&gt;Also, I learned today that when a node goes away like this (iptables method)&lt;br/&gt;
it will take aprox 3.5m before we remove it from operational.  When I was&lt;br/&gt;
doing this test earlier today I was not waiting that long.  I wonder if&lt;br/&gt;
there is any difference there.  I have a feeling your step 6 (reboot) will&lt;br/&gt;
actively close the ovs connection so the plugin will see the TCP connection&lt;br/&gt;
closed and might immediately remove it from operational.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;br/&gt;
JamO&lt;/p&gt;</comment>
                            <comment id="41226" author="vinh.nguyen@hcl.com" created="Tue, 19 Apr 2016 23:38:10 +0000"  >&lt;p&gt;(In reply to Jamo Luhrsen from comment #5)&lt;br/&gt;
&amp;gt; (In reply to Vinh Nguyen from comment #4)&lt;br/&gt;
&amp;gt; &amp;gt; (In reply to Jamo Luhrsen from comment #3)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; (In reply to Vinh Nguyen from comment #2)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; Code review submitted:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I tried to test this patch, but saw the same behavior of this bug.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; However, I had some trouble building the patch to create a distribution.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I was using our multipatch job in the sandbox, which will create an&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; entire distribution based on any patches.  I used this patch for that&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; job, but it failed when building with master (Boron).  The failure was&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; in yangtools (warning message below) so probably nothing wrong with the&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; patch.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; But pulling this patch in to the stable/beryllium branch I got a distribution&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; to build.  Using that distribution, I re-tested this bug and saw the &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; same behavior.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;WARNING&amp;#93;&lt;/span&gt; Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; org/opendaylight/yangtools/yang2sources/plugin/YangToSourcesMojo :&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Unsupported major.minor version 52.0&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Hi Jamo,&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; I was able to verify the bug on the stable/beryllium branch. There are the &lt;br/&gt;
&amp;gt; &amp;gt; reproduction steps, please let me know if I missed something:&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 1) git checkout stable/beryllium&lt;br/&gt;
&amp;gt; &amp;gt; 2) chery-pick the patch: &lt;br/&gt;
&amp;gt; &amp;gt;    git fetch &lt;a href=&quot;https://git.opendaylight.org/gerrit/ovsdb&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/ovsdb&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; refs/changes/58/37358/1 &amp;amp;&amp;amp; git cherry-pick FETCH_HEAD&lt;br/&gt;
&amp;gt; &amp;gt; 3) build and run karaf&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 4) connect an ovs node to controller&lt;br/&gt;
&amp;gt; &amp;gt;    sudo ovs-vsctl set-manager tcp:${IP}:6640&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 5) create a bridge in config store and verify it&apos;s there in operational&lt;br/&gt;
&amp;gt; &amp;gt;     and on ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 6) reboot the ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 7) while ovs node disconnected, create a new bridge in config store&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 8) when the ovs comes back up, verify that the bridge created in 5 and 7 are&lt;br/&gt;
&amp;gt; &amp;gt; present in the operational as well as on ovs node.&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Thanks, Vinh&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I can try again using your steps 1-3.  Could you try again as well, and&lt;br/&gt;
&amp;gt; instead of doing your step 6, can you run this command on your ovs node:&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt;   iptables -A OUTPUT -p tcp --dport 6640 -j DROP&quot;&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; that will simulate the ovs node &quot;going away&quot;.  While it&apos;s in that state,&lt;br/&gt;
&amp;gt; ovs-vsctl should show it&apos;s not connected.  Now, you can go back to your&lt;br/&gt;
&amp;gt; step 7 and 8.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Also, I learned today that when a node goes away like this (iptables method)&lt;br/&gt;
&amp;gt; it will take aprox 3.5m before we remove it from operational.  When I was&lt;br/&gt;
&amp;gt; doing this test earlier today I was not waiting that long.  I wonder if&lt;br/&gt;
&amp;gt; there is any difference there.  I have a feeling your step 6 (reboot) will&lt;br/&gt;
&amp;gt; actively close the ovs connection so the plugin will see the TCP connection&lt;br/&gt;
&amp;gt; closed and might immediately remove it from operational.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Thanks,&lt;br/&gt;
&amp;gt; JamO&lt;/p&gt;

&lt;p&gt;Hi JamO,&lt;/p&gt;

&lt;p&gt;I also can verify the fix using iptables command for step 6) and remove the rule in step 8)&lt;/p&gt;

&lt;p&gt;In step 6) after about couple minutes the node is removed from the datastore. &lt;br/&gt;
In step 8Then (In reply to Jamo Luhrsen from comment #5)&lt;br/&gt;
&amp;gt; (In reply to Vinh Nguyen from comment #4)&lt;br/&gt;
&amp;gt; &amp;gt; (In reply to Jamo Luhrsen from comment #3)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; (In reply to Vinh Nguyen from comment #2)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; Code review submitted:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I tried to test this patch, but saw the same behavior of this bug.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; However, I had some trouble building the patch to create a distribution.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I was using our multipatch job in the sandbox, which will create an&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; entire distribution based on any patches.  I used this patch for that&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; job, but it failed when building with master (Boron).  The failure was&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; in yangtools (warning message below) so probably nothing wrong with the&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; patch.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; But pulling this patch in to the stable/beryllium branch I got a distribution&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; to build.  Using that distribution, I re-tested this bug and saw the &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; same behavior.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;WARNING&amp;#93;&lt;/span&gt; Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; org/opendaylight/yangtools/yang2sources/plugin/YangToSourcesMojo :&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Unsupported major.minor version 52.0&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Hi Jamo,&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; I was able to verify the bug on the stable/beryllium branch. There are the &lt;br/&gt;
&amp;gt; &amp;gt; reproduction steps, please let me know if I missed something:&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 1) git checkout stable/beryllium&lt;br/&gt;
&amp;gt; &amp;gt; 2) chery-pick the patch: &lt;br/&gt;
&amp;gt; &amp;gt;    git fetch &lt;a href=&quot;https://git.opendaylight.org/gerrit/ovsdb&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/ovsdb&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; refs/changes/58/37358/1 &amp;amp;&amp;amp; git cherry-pick FETCH_HEAD&lt;br/&gt;
&amp;gt; &amp;gt; 3) build and run karaf&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 4) connect an ovs node to controller&lt;br/&gt;
&amp;gt; &amp;gt;    sudo ovs-vsctl set-manager tcp:${IP}:6640&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 5) create a bridge in config store and verify it&apos;s there in operational&lt;br/&gt;
&amp;gt; &amp;gt;     and on ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 6) reboot the ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 7) while ovs node disconnected, create a new bridge in config store&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 8) when the ovs comes back up, verify that the bridge created in 5 and 7 are&lt;br/&gt;
&amp;gt; &amp;gt; present in the operational as well as on ovs node.&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Thanks, Vinh&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I can try again using your steps 1-3.  Could you try again as well, and&lt;br/&gt;
&amp;gt; instead of doing your step 6, can you run this command on your ovs node:&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt;   iptables -A OUTPUT -p tcp --dport 6640 -j DROP&quot;&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; that will simulate the ovs node &quot;going away&quot;.  While it&apos;s in that state,&lt;br/&gt;
&amp;gt; ovs-vsctl should show it&apos;s not connected.  Now, you can go back to your&lt;br/&gt;
&amp;gt; step 7 and 8.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Also, I learned today that when a node goes away like this (iptables method)&lt;br/&gt;
&amp;gt; it will take aprox 3.5m before we remove it from operational.  When I was&lt;br/&gt;
&amp;gt; doing this test earlier today I was not waiting that long.  I wonder if&lt;br/&gt;
&amp;gt; there is any difference there.  I have a feeling your step 6 (reboot) will&lt;br/&gt;
&amp;gt; actively close the ovs connection so the plugin will see the TCP connection&lt;br/&gt;
&amp;gt; closed and might immediately remove it from operational.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Thanks,&lt;br/&gt;
&amp;gt; JamO&lt;/p&gt;

&lt;p&gt;Hi JamO,&lt;/p&gt;

&lt;p&gt;I can verify the fix using the iptables command to add/delete firewall rules in step 6 and 8 respectively.&lt;br/&gt;
In step 6, the ovs is disconnected after (In reply to Jamo Luhrsen from comment #5)&lt;br/&gt;
&amp;gt; (In reply to Vinh Nguyen from comment #4)&lt;br/&gt;
&amp;gt; &amp;gt; (In reply to Jamo Luhrsen from comment #3)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; (In reply to Vinh Nguyen from comment #2)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; Code review submitted:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I tried to test this patch, but saw the same behavior of this bug.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; However, I had some trouble building the patch to create a distribution.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I was using our multipatch job in the sandbox, which will create an&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; entire distribution based on any patches.  I used this patch for that&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; job, but it failed when building with master (Boron).  The failure was&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; in yangtools (warning message below) so probably nothing wrong with the&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; patch.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; But pulling this patch in to the stable/beryllium branch I got a distribution&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; to build.  Using that distribution, I re-tested this bug and saw the &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; same behavior.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;WARNING&amp;#93;&lt;/span&gt; Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; org/opendaylight/yangtools/yang2sources/plugin/YangToSourcesMojo :&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Unsupported major.minor version 52.0&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Hi Jamo,&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; I was able to verify the bug on the stable/beryllium branch. There are the &lt;br/&gt;
&amp;gt; &amp;gt; reproduction steps, please let me know if I missed something:&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 1) git checkout stable/beryllium&lt;br/&gt;
&amp;gt; &amp;gt; 2) chery-pick the patch: &lt;br/&gt;
&amp;gt; &amp;gt;    git fetch &lt;a href=&quot;https://git.opendaylight.org/gerrit/ovsdb&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/ovsdb&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; refs/changes/58/37358/1 &amp;amp;&amp;amp; git cherry-pick FETCH_HEAD&lt;br/&gt;
&amp;gt; &amp;gt; 3) build and run karaf&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 4) connect an ovs node to controller&lt;br/&gt;
&amp;gt; &amp;gt;    sudo ovs-vsctl set-manager tcp:${IP}:6640&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 5) create a bridge in config store and verify it&apos;s there in operational&lt;br/&gt;
&amp;gt; &amp;gt;     and on ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 6) reboot the ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 7) while ovs node disconnected, create a new bridge in config store&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 8) when the ovs comes back up, verify that the bridge created in 5 and 7 are&lt;br/&gt;
&amp;gt; &amp;gt; present in the operational as well as on ovs node.&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Thanks, Vinh&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I can try again using your steps 1-3.  Could you try again as well, and&lt;br/&gt;
&amp;gt; instead of doing your step 6, can you run this command on your ovs node:&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt;   iptables -A OUTPUT -p tcp --dport 6640 -j DROP&quot;&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; that will simulate the ovs node &quot;going away&quot;.  While it&apos;s in that state,&lt;br/&gt;
&amp;gt; ovs-vsctl should show it&apos;s not connected.  Now, you can go back to your&lt;br/&gt;
&amp;gt; step 7 and 8.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Also, I learned today that when a node goes away like this (iptables method)&lt;br/&gt;
&amp;gt; it will take aprox 3.5m before we remove it from operational.  When I was&lt;br/&gt;
&amp;gt; doing this test earlier today I was not waiting that long.  I wonder if&lt;br/&gt;
&amp;gt; there is any difference there.  I have a feeling your step 6 (reboot) will&lt;br/&gt;
&amp;gt; actively close the ovs connection so the plugin will see the TCP connection&lt;br/&gt;
&amp;gt; closed and might immediately remove it from operational.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Thanks,&lt;br/&gt;
&amp;gt; JamO&lt;/p&gt;

&lt;p&gt;(In reply to Jamo Luhrsen from comment #5)&lt;br/&gt;
&amp;gt; (In reply to Vinh Nguyen from comment #4)&lt;br/&gt;
&amp;gt; &amp;gt; (In reply to Jamo Luhrsen from comment #3)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; (In reply to Vinh Nguyen from comment #2)&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; Code review submitted:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &amp;gt; &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/37358/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/37358/&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I tried to test this patch, but saw the same behavior of this bug.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; However, I had some trouble building the patch to create a distribution.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; I was using our multipatch job in the sandbox, which will create an&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; entire distribution based on any patches.  I used this patch for that&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; job, but it failed when building with master (Boron).  The failure was&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; in yangtools (warning message below) so probably nothing wrong with the&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; patch.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; But pulling this patch in to the stable/beryllium branch I got a distribution&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; to build.  Using that distribution, I re-tested this bug and saw the &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; same behavior.&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;WARNING&amp;#93;&lt;/span&gt; Failed to notify spy hudson.maven.Maven3Builder$JenkinsEventSpy:&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; org/opendaylight/yangtools/yang2sources/plugin/YangToSourcesMojo :&lt;br/&gt;
&amp;gt; &amp;gt; &amp;gt; Unsupported major.minor version 52.0&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Hi Jamo,&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; I was able to verify the bug on the stable/beryllium branch. There are the &lt;br/&gt;
&amp;gt; &amp;gt; reproduction steps, please let me know if I missed something:&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 1) git checkout stable/beryllium&lt;br/&gt;
&amp;gt; &amp;gt; 2) chery-pick the patch: &lt;br/&gt;
&amp;gt; &amp;gt;    git fetch &lt;a href=&quot;https://git.opendaylight.org/gerrit/ovsdb&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/ovsdb&lt;/a&gt;&lt;br/&gt;
&amp;gt; &amp;gt; refs/changes/58/37358/1 &amp;amp;&amp;amp; git cherry-pick FETCH_HEAD&lt;br/&gt;
&amp;gt; &amp;gt; 3) build and run karaf&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 4) connect an ovs node to controller&lt;br/&gt;
&amp;gt; &amp;gt;    sudo ovs-vsctl set-manager tcp:${IP}:6640&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 5) create a bridge in config store and verify it&apos;s there in operational&lt;br/&gt;
&amp;gt; &amp;gt;     and on ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 6) reboot the ovs node&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 7) while ovs node disconnected, create a new bridge in config store&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; 8) when the ovs comes back up, verify that the bridge created in 5 and 7 are&lt;br/&gt;
&amp;gt; &amp;gt; present in the operational as well as on ovs node.&lt;br/&gt;
&amp;gt; &amp;gt; &lt;br/&gt;
&amp;gt; &amp;gt; Thanks, Vinh&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Vinh,&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; I can try again using your steps 1-3.  Could you try again as well, and&lt;br/&gt;
&amp;gt; instead of doing your step 6, can you run this command on your ovs node:&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt;   iptables -A OUTPUT -p tcp --dport 6640 -j DROP&quot;&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; that will simulate the ovs node &quot;going away&quot;.  While it&apos;s in that state,&lt;br/&gt;
&amp;gt; ovs-vsctl should show it&apos;s not connected.  Now, you can go back to your&lt;br/&gt;
&amp;gt; step 7 and 8.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Also, I learned today that when a node goes away like this (iptables method)&lt;br/&gt;
&amp;gt; it will take aprox 3.5m before we remove it from operational.  When I was&lt;br/&gt;
&amp;gt; doing this test earlier today I was not waiting that long.  I wonder if&lt;br/&gt;
&amp;gt; there is any difference there.  I have a feeling your step 6 (reboot) will&lt;br/&gt;
&amp;gt; actively close the ovs connection so the plugin will see the TCP connection&lt;br/&gt;
&amp;gt; closed and might immediately remove it from operational.&lt;br/&gt;
&amp;gt; &lt;br/&gt;
&amp;gt; Thanks,&lt;br/&gt;
&amp;gt; JamO&lt;/p&gt;

&lt;p&gt;Hi JamO,&lt;/p&gt;

&lt;p&gt;I can verify the fix successfully using iptables command to add/delete firewall rules for step6 and 8 respectively.&lt;br/&gt;
In step 6, the connection is disconnected after 3-4 minutes and the configurations are removed from the datastore&lt;/p&gt;

&lt;p&gt;In step 8 after removing the firewall, the node is reconnected and new configurations are reconciled like the reboot scenario.&lt;/p&gt;

&lt;p&gt;Thanks, Vinh&lt;/p&gt;</comment>
                            <comment id="41227" author="shague@redhat.com" created="Mon, 16 May 2016 20:49:47 +0000"  >&lt;p&gt;be: &lt;a href=&quot;https://git.opendaylight.org/gerrit/38531&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/38531&lt;/a&gt;&lt;br/&gt;
b: &lt;a href=&quot;https://git.opendaylight.org/gerrit/37358&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/37358&lt;/a&gt;&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>5177</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=5177]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10305"><![CDATA[Improvement]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i021sf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>