https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETVIRT-819 netvirt <p>Description of problem<br/> =======================<br/> After deployment when launching an instance - it doesn't get an IP.<br/> When launching a second instance on the same node - it gets and IP.<br/> Then when rebooting the first one - it gets an IP</p> <p>Version<br/> =======<br/> opendaylight-6.1.0-2.el7ost.noarch</p> <p>Steps to Reproduce<br/> =====================<br/> 1.Deploy an overcloud<br/> 2.Launch an instance.<br/> 3.Open The proper security group rules<br/> 4.Verify that it doesn't get an IP (can be pinged from the DHCP name space).<br/> 5.Launch an instance on the same node as the first one and make sure it gets an IP.</p> <p>Operating System: All<br/> Platform: All</p> NETVIRT-819

An instance doesn't get an IP after deployment

Bug Verified Done Sridhar Gaddam Itzik Brown Thu, 3 Aug 2017 13:53:29 +0000 Thu, 3 May 2018 15:10:39 +0000 Mon, 28 Aug 2017 06:54:14 +0000 Carbon General 0 4 <p>Also seen in TripleO CI. See tripleo_ci attachment. We need to get logs for flow dumps and ODL which are missing right now in OOO CI.</p> <p>Attachment overcloud_validate.log.txt.gz has been added with description: tripleo_ci_log</p> <p>In a fresh multinode deployment with Controller node running<br/> ODL + dhcp-agent and a Compute node, when we spawn a first VM<br/> on the compute node, it was seen that VM does not acquire the<br/> IPAddress. On debugging, it turns out that the remote broadcast<br/> group entries were not programmed on the Compute node. </p> <p>Setup details:<br/> 1. Multi-node with Controller and a Compute node.<br/> 2. Create a tenant neutron network with an IPv4 subnet.<br/> 3. Create a neutron router.<br/> 4. Associate the ipv4 subnet to the neutron router.</p> <p>At this stage, you can see that there is no tunnel between<br/> Controller node and Compute node.</p> <p>5. Now spawn a VM on the Compute node (you can explicitly<br/> specify that VM has to be spawned on the compute node<br/> by passing --availability-zone to nova boot command).</p> <p>When the VM is spawned, following would be the sequence<br/> of events.</p> <p>t1: Nova creates a tap interface for the VM, this translates<br/> to an add event for elanInterface (i.e., ElanInterfaceStateChangeListener<br/> is invoked, and addElanInterface gets processed)<br/> t2: In addElanInterface, elanManager checks if the interface<br/> is part of existingElanDpnInterfaces (i.e., DpnInterfaces YANG model)<br/> t3: Since its a new interface, it invokes createElanInterfacesList()<br/> which would update the DpnInterfaces model. At this stage, the<br/> transaction/information is still not comitted to the datastore.<br/> t4: The processing continues to installEntriesForFirstInterfaceonDpn(),<br/> where we try to program the local/remote BC Group entries. <br/> In this API, we have an explicit sleep for (300 + 300) ms and when we<br/> try to query the getEgressActionsForInterface (which is an API in GENIUS).<br/> GENIUS returns an empty list with the following reason - "Interface<br/> information not present in oper DS for the tunnel interface".<br/> t5: So the remote BC Group does not include the actions to send the<br/> packets over the tunnel interface at this stage.<br/> t6: addElanInterface processing continues further and we commit the<br/> transaction (i.e., DpnInterfaces model is now updated in the datastore).</p> <p>While t1 to t6 is going on, in parallel, auto-tunnel code in GENIUS<br/> creates the tunnel interfaces.</p> <p>A1: A tunnel interface is created on the Compute node. When the tunnel interface<br/> state is up, TunnelsState YANG model is updated in GENIUS (ItmTunnelStateUpdateHelper).<br/> A2: A notification is received in ElanTunnelInterfaceStateListener, which<br/> is handled in the following api - handleInternalTunnelStateEvent.<br/> A3: In this API, when we query the ElanDpnInterfaces it only includes<br/> the DPNInfo of the Controller and not the Compute node (because of<br/> the delay in updating the model step t3-t6 above) <br/> A4: Due to this, in handleInternalTunnelStateEvent, we do not invoke<br/> setupElanBroadcastGroups() to program the Remote Group entries<br/> on the Compute node and the remote Broadcast Group entries on<br/> the Compute node never get updated.</p> <p>So, the fix is, not to delay the updation of model (i.e., DpnInterfaces<br/> until step t6) since this information is used while processing<br/> ElanTunnelInterfaceState.</p> <p>The following patch would address this issue:<br/> <a href="https://git.opendaylight.org/gerrit/#/c/61995/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/61995/</a></p> <p>nitrogen and master are merged. Waiting for carbon.</p> <p>master: <a href="https://git.opendaylight.org/gerrit/#/c/62015/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/62015/1</a><br/> nitrogen: <a href="https://git.opendaylight.org/gerrit/#/c/62014/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/62014/1</a></p> <p>A patch was submitted to revert the changes and fix this bug in Carbon SR2:</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/61995/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/61995/</a></p> <p>To better assess the impact of this bug and fix, could someone from your team please help us identify the following:<br/> Regression: Is this bug a regression of functionality/performance/feature compared to Carbon?<br/> Severity: Could you elaborate on the severity of this bug? Is this a BLOCKER such that we cannot release Carbon SR2 without it?<br/> Workaround: Is there a workaround such that we can write a release note instead?<br/> Testing: Could you also elaborate on the testing of this patch? How extensively has this patch been tested? Is it covered by any unit tests or system tests? <br/> Impact: Does this fix impact any dependent projects?</p> <p>(In reply to A H from comment #7)<br/> &gt; A patch was submitted to revert the changes and fix this bug in Carbon SR2:<br/> &gt; <br/> &gt; <a href="https://git.opendaylight.org/gerrit/#/c/61995/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/61995/</a><br/> &gt; <br/> &gt; To better assess the impact of this bug and fix, could someone from your<br/> &gt; team please help us identify the following:<br/> &gt; Regression: Is this bug a regression of functionality/performance/feature<br/> &gt; compared to Carbon?<br/> Yes, AFAIK its a regression.</p> <p>&gt; Severity: Could you elaborate on the severity of this bug? Is this a<br/> &gt; BLOCKER such that we cannot release Carbon SR2 without it?<br/> Yes, its a blocker bug for a Multi-node setup. </p> <p>&gt; Workaround: Is there a workaround such that we can write a release note<br/> &gt; instead?<br/> One work-around is to create manual tunnels and not rely on the auto-tunnel code, but this is not an acceptable solution to many users.</p> <p>&gt; Testing: Could you also elaborate on the testing of this patch? How<br/> &gt; extensively has this patch been tested? Is it covered by any unit tests or<br/> &gt; system tests? <br/> The issue is seen in TripleO CI and also in our downstream multi-node setup. </p> <p>&gt; Impact: Does this fix impact any dependent projects?<br/> No</p> <p>OPNFV Functest is now passing with the fix:<br/> <a href="https://build.opnfv.org/ci/job/apex-verify-master/756/" class="external-link" target="_blank" rel="nofollow noopener">https://build.opnfv.org/ci/job/apex-verify-master/756/</a></p> <p>(In reply to Timothy Rozet from comment #9)<br/> &gt; OPNFV Functest is now passing with the fix:<br/> &gt; <a href="https://build.opnfv.org/ci/job/apex-verify-master/756/" class="external-link" target="_blank" rel="nofollow noopener">https://build.opnfv.org/ci/job/apex-verify-master/756/</a></p> <p>Thanks @Tim for confirming that fix is working.</p> Development External issue ID 8926 External issue URL ODL SR Target Milestone Rank 0|i01u5j: