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/OVSDB-406 ovsdb <p>Today physical locator creation is driven from controller , but not deletion.<br/> Physical locator can be deleted from the device database , when the device sees no references to it.</p> <p>This is posing some problems with subsequent creations.<br/> When mcast mac1 is created along with locator1</p> <p>The operational datastore contains locator1 and its uuid.</p> <p>Now if the following updates come.<br/> at time T1)Delete mcast mac1<br/> at time T2)Insert mcast mac2 ( referring to locator1 )</p> <p>First odl controller will fire delete mcast mac1 to device.<br/> The device acknowledges success for the transaction.</p> <p>In the background <br/> The device also deletes locator1 as its only reference is gone and sends an update to the controller ( let us say this sending the delete update to controller is delayed by a sec ).</p> <p>Before that previous event happens if Insert mcast mac2 event comes, controller uses the uuid of locator1 to create mac2.<br/> This insertion of mac2 fails with error saying such a foreign key does not exist.</p> <p>Controller has no clue that device is going to delete locator1 and went ahead used its uuid to create mac2 which resulted in this error.</p> <p>Operating System: All<br/> Platform: All</p> OVSDB-406

Proper handling of json rpc transactions involving deletes particularly physical locators

Bug Verified Done suneelu varma suneel verma Tue, 21 Mar 2017 10:01:52 +0000 Wed, 21 Mar 2018 17:39:29 +0000 Wed, 21 Mar 2018 16:51:25 +0000 Oxygen Oxygen Southbound.hw_vtep 0 4 <p>Hi Suneel,</p> <p>Do you have any specific approach to fix it ? How about if controller create the mcast mac2 first and then delete mac1 to avoid this situation? Will device throw error if the mac1 already exist for the physical locator?</p> <p>How about if controller create the mcast mac2 first and then delete mac1 to avoid this situation?</p> <p>When mac1 delete event came , controller does know that it is going to be followed by insert of mac2 which uses some of the locators of mac1.</p> <p>It simply acts on the mac1 delete event. That way we cannot put it on hold.</p> <p>Moreover this situation can happen for other references of locators like , remote ucast macs and tunnels.</p> <p>Two approaches I was thinking.</p> <p>Approach1.<br/> Simply retry the insert transaction after some configured delay.</p> <p>Since we put a delay here for retry, by the time it gets rescheduled,<br/> the locator delete event comes from device,<br/> it gets cleared from operational data store.<br/> As part of re-execution of event post the delay it sees that locator is not present and goes ahead and creates one.</p> <p>Approach2<br/> Maintain a ref count on locator from config side.<br/> When the ref count goes down to zero , put the locator in transit state.</p> <p>Now the insert of mac2 event comes.<br/> It sees that its locator state is in transit.<br/> When we see our dependency is in transit, it is pushed to dependency queue for all its dependencies to be resolved.</p> <p>If the device actually deletes the locator , then the locator is removed<br/> from in transit state let us say with in the next 100ms or so.</p> <p>Then the event (insert mac2 ) which got pushed to queue gets executed since its dependency is resolved from in transit state.<br/> As part of processing this event (insert mac2 ), it goes ahead and creates locator.</p> <p>If there is a bug in refcounting the locator references ( actually there are references but we thought it is going to be deleted by looking at zero ref count and placed the locator in transit state ),</p> <p>then the device does not delete the locator</p> <p>The dependency queue event (insert mac2) ages out (expires) in 30secs (configured time) and proceeds with the original locator uuid to do insertion of mac.</p> <p>Also discussing the same on patch<br/> <a href="https://git.opendaylight.org/gerrit/#/c/53594/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53594/</a></p> <p>I am not very confident about the delay based approach, so the first approach looks bit risky and probably can introduce some race conditions etc. Second approach is probably the better approach. As per vtep schema, Physical Locator is referenced by Physical_Locator_Set,Ucast_Macs_Local and Ucast_Macs_Remote. It shows that Ucast_Macs_Local, Ucast_Macs_Remote both are having one to one mapping with physical locator, except Physical_Locator_Set. Physical_Locator_Set is something that is just holding the reference. Given that Ucast_Macs_Local, Ucast_Macs_Remote both has one to one mapping with Physical_Locator, i am wondering if we can club the create/delete of Physical_Locator with Ucast_Macs_Local, Ucast_Macs_Remote create/delete operations. So rather than relying on switch to automatically do that, let the controller explictly do it, that way the functional behavior of the plugin will be more deterministic.</p> <p>Ucast mac controlling the creation and deletion of locator makes sense.</p> <p>Today One more variable in picture is tunnel. That is also creating the locator if it does not exist.</p> <p>So in the approach2 if we replace mcast mac1 and mcast mac2 as ucast mac1 and ucast mac2 , does it sound ok ?</p> <p>The only downside of this approach as i was talking is some times it causes unnecessary delays (upto precofigured delay 10-30sec) if the ref counting goes to zero ( if at all a bug is there in ref counting ).</p> <p>I have made the changes to add ref count and verified using the suggested approach.<br/> It works fine except for mcast macs.<br/> After adding refcounts for locators referred by mcast macs along with ucast macs, it works fine.</p> <p>review in progress<br/> <a href="https://git.opendaylight.org/gerrit/61535" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/61535</a></p> Development External issue ID 8029 External issue URL Rank 0|i022jb: