> On Fri, Jun 14, 2019 at 05:53:20PM +0200, Lorenzo Bianconi wrote: > > The series here introduces a new table, Controller_Event, for this > > purpose. Traffic into OVS can raise a controller() event that results in > > a Controller_Event being written to the southbound database. The > > intention is for a CMS to see the events and take some sort of action. > > The "handled" column of the event is initially set to "false" by OVN. > > When the CMS has seen the event and taken appropriate action, then the > > CMS sets this field to "true'. When ovn-controller sees that the event > > has been handled, it deletes the event from the database. > > > > Controller events are only added to the southbound database if they have > > been enabled in the nb_global table via the options:controller_event > > setting. > > The above paragraphs of high-level information are helpful, but they are > only in email and do not appear in the documentation. I suggest adding > them to the documentation so that the reader can see the whole picture. > > Some other high-level design comments: > > - I don't see an explanation of the sequence number and how it's used in > practice. > > - I don't yet understand why it's better to have the CMS set 'handled' > and then have ovn-controller delete the row, than to have the CMS > delete the row directly.
Hi Ben, thx for the review. I think controlling 'handled' field in a single point make the system more robust against races but we can just move the control to the CMS. I will post a v2 soon. Regards, Lorenzo > > - The passive voice in the second paragraph above makes it ambiguous who > sets options:controller_event. I think that the CMS sets this; it > would be best for the documentation to say so. > > Thanks, > > Ben.
_______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
