<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 7:51 AM, Numan Siddique <span dir="ltr"><<a href="mailto:nusiddiq@redhat.com" target="_blank">nusiddiq@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><font face="arial, helvetica, sans-serif">Thanks for the comments Amitabha.</font></div><div><font face="arial, helvetica, sans-serif">Please see comments inline</font></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Jul 22, 2016 at 5:50 AM, Amitabha Biswas <span dir="ltr"><<a href="mailto:azbiswas@gmail.com" target="_blank">azbiswas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Numan,<div><br></div><div>Thanks for the proposal. We have also been thinking about this use-case.<br><div><br></div><div>If I’m reading this accurately (and I may not be), it seems that the proposal is to not have any OVN NB (CUD) operations (R operations outside the scope) done by the api_worker threads but rather by a new journal thread.</div><div><br></div></div></div></blockquote><div><br></div></span><div><div style="display:inline"><font face="arial, helvetica, sans-serif">Correct.</font></div></div><span class=""><div><div style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>If this is indeed the case, I’d like to consider the scenario when there any N neutron nodes, each node with M worker threads. The journal thread at the each node contain list of pending operations. Could there be (sequence) dependency in the pending operations amongst each the journal threads in the nodes that prevents them from getting applied (for e.g. Logical_Router_Port and Logical_Switch_Port inter-dependency), because we are returning success on neutron operations that have still not been committed to the NB DB.</div><div><br></div></div></div></blockquote><div><font face="arial, helvetica, sans-serif"><br></font></div></span><div><font face="arial, helvetica, sans-serif">I<div style="display:inline">ts a valid scenario and should be designed properly to handle such scenarios in case we take this approach.</div></font></div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">I believe a new table in the Neutron DB is used to synchronize all of the journal threads.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"></div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Also note that OVN currently has no custom tables in the Neutron database and it would be *very* good to keep it that way if we can.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><font face="arial, helvetica, sans-serif"><div style="display:inline"> </div></font></div><span class=""><div><font face="monospace, monospace"><div style="font-family:monospace,monospace;display:inline"><br></div></font></div><div><font face="monospace, monospace"><div style="font-family:monospace,monospace;display:inline"></div></font></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>Couple of clarifications and thoughts below.</div><div><br></div><div>Thanks</div><div>Amitabha <<a href="mailto:abiswas@us.ibm.com" target="_blank">abiswas@us.ibm.com</a>></div><div><br><div><span><blockquote type="cite"><div>On Jul 13, 2016, at 1:20 AM, Numan Siddique <<a href="mailto:nusiddiq@redhat.com" target="_blank">nusiddiq@redhat.com</a>> wrote:</div><br><div><div dir="ltr"><div><font face="arial, helvetica, sans-serif">Adding the proper tags in subject</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 1:22 PM, Numan Siddique <span dir="ltr"><<a href="mailto:nusiddiq@redhat.com" target="_blank">nusiddiq@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><font face="arial, helvetica, sans-serif">Hi Neutrinos,<br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Presently, In the OVN ML2 driver we have 2 ways to sync neutron DB and OVN DB</font></div><div><font face="arial, helvetica, sans-serif"> - At neutron-server startup, OVN ML2 driver syncs the neutron DB and OVN DB if sync mode is set to repair.</font></div><div><font face="arial, helvetica, sans-serif"> - Admin can run the "neutron-ovn-db-sync-util" to sync the DBs.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Recently, in the v2 of networking-odl ML2 driver (Please see (1) below which has more details). (ODL folks please correct me if I am wrong here)</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"> - a journal thread is created which does the CRUD operations of neutron resources asynchronously (i.e it sends the REST APIs to the ODL controller).</font></div></div></div></blockquote></div></div></div></div></blockquote><br></span>Would this be the equivalent of making OVSDB transactions to the OVN NB DB?</div></div></div></div></blockquote><div><br></div></span><div><div style="display:inline"><font face="arial, helvetica, sans-serif">Correct.</font></div></div><div><div class="h5"><div><div style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><span><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><font face="arial, helvetica, sans-serif"> - a maintenance thread is created which does some cleanup periodically and at startup does full sync if it detects ODL controller cold reboot.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Few question I have</font></div><div><font face="arial, helvetica, sans-serif"> - can OVN ML2 driver take same or similar approach. Are there any advantages in taking this approach ? One advantage is neutron resources can be created/updated/deleted even if the OVN ML2 driver has lost connection to the ovsdb-server. The journal thread would eventually sync these resources in the OVN DB. I would like to know the communities thoughts on this.</font></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div></span></div></div></div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I question whether making operations appear to be successful even when ovsdb-server is unreachable is a useful thing. API calls fail today if the Neutron db is unreachable. Why would we bend over backwards for the OVN database?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If this was easy to do, sure, but this solution seems *incredibly* complex to me, so I see it as an absolute last resort.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><span><div></div></span>If we can make it work, it would indeed be a huge plus for system wide upgrades and some corner cases in the code (ACL specifically), where the post_commit relies on all transactions to be successful and doesn’t revert the neutron db if something fails.</div></div></div></div></blockquote><div><br></div></div></div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Can we just improve the ML2 framework to make this problem easier to deal with? This problem would affect several drivers. Driver specific partial solutions just keep getting replicated. I'd like to see if we can solve the problems more generally.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><br><blockquote type="cite"><div><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"> - Are there are other ML2 drivers which might have to handle the DB sync's (cases where the other controllers also maintain their own DBs) and how they are handling it ?</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"> - Can a common approach be taken to sync the neutron DB and controller DBs ?</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">-----------------------------------------------------------------------------------------------------------</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">(1)</font></div><div><font face="arial, helvetica, sans-serif">Sync threads created by networking-odl ML2 driver</font></div><div><font face="arial, helvetica, sans-serif">--------------------------------------------------</font></div><div><font face="arial, helvetica, sans-serif">ODL ML2 driver creates 2 threads (threading.Thread module) at init</font></div><div><font face="arial, helvetica, sans-serif"> - Journal thread</font></div><div><font face="arial, helvetica, sans-serif"> - Maintenance thread</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Journal thread</font></div><div><font face="arial, helvetica, sans-serif">----------------</font></div><div><font face="arial, helvetica, sans-serif">The journal module creates a new journal table by name “opendaylightjournal” - <a href="https://github.com/openstack/networking-odl/blob/master/networking_odl/db/models.py#L23" target="_blank">https://github.com/openstack/networking-odl/blob/master/networking_odl/db/models.py#L23</a></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Journal thread will be in loop waiting for the sync event from the ODL ML2 driver.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"> - ODL ML2 driver resource (network, subnet, port) precommit functions when called by the ML2 plugin adds an entry in the “opendaylightjournal” table with the resource data and sets the journal operation state for this entry to “PENDING”.</font></div><div><font face="arial, helvetica, sans-serif"> - The corresponding resource postcommit function of the ODL ML2 plugin when called, sets the sync event flag.</font></div><div><font face="arial, helvetica, sans-serif"> - A timer is also created which sets the sync event flag when it expires (the default value is 10 seconds).</font></div><div><font face="arial, helvetica, sans-serif"> - Journal thread wakes up, looks into the “opendaylightjournal” table with the entries with state “pending” and runs the CRUD operation on those resources in the ODL DB. Once done, it sets the state to “completed”.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Maintenance thread</font></div><div><font face="arial, helvetica, sans-serif">------------------</font></div><div><font face="arial, helvetica, sans-serif">Maintenance thread does 3 operations</font></div><div><font face="arial, helvetica, sans-serif"> - JournalCleanup - Delete completed rows from journal table “opendaylightjournal”.</font></div><div><font face="arial, helvetica, sans-serif"> - CleanupProcessing - Mark orphaned processing rows to pending.</font></div><div><font face="arial, helvetica, sans-serif"> - Full sync - Re-sync when detecting an ODL "cold reboot”.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Thanks</font></div><span><font color="#888888"><div><font face="arial, helvetica, sans-serif">Numan</font></div><div style="font-family:monospace,monospace"><br></div></font></span></div></div>
</blockquote></div><br></div></div></div></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="arial, helvetica, sans-serif">Russell Bryant</font></div></div></div></div></div>
</div></div>