On Mon, Jul 18, 2016 at 2:30 PM, Ben Pfaff <b...@ovn.org> wrote: > Until now, there has been no reliable for the CMS (or ovn-nbctl, or > anything else) to detect when changes made to the northbound configuration > have been passed through to the southbound database or to the hypervisors. > This commit adds this feature to the system, by adding sequence numbers > to the northbound and southbound databases and adding code in ovn-nbctl, > ovn-northd, and ovn-controller to keep those sequence numbers up-to-date. > > The biggest user-visible change from this commit is new a new option > --wait to ovn-nbctl. With --wait=sb, ovn-nbctl now waits for ovn-northd > to update the southbound database; with --wait=hv, it waits for the > changes to make their way to Open vSwitch on every hypervisor. > > Signed-off-by: Ben Pfaff <b...@ovn.org> > --- > v1->v2: Rebase to fix up database version number. >
Cool feature. :-) Thanks a lot for the detailed documentation. That made it easy to understand how this is to be used. I was trying to decide if the OpenStack Neutron plugin would make use of this. We currently use the 'up' column of Logical_Switch_Port. As you point out in docs, "up" means something different, as it signals the successful binding of a port to a chassis. I think that's really what we want and would continue using. A downside I thought of to using this from something like Neutron is that it would block the whole cloud any time there's any sort of problem with any hypervisor, which I don't think is desirable. The feature still sounds very useful for testing and debugging, at a minimum. If this all makes sense, then I can proceed with a more detailed review of the implementation. Thanks, + /* Track the flow update. */ > + struct ofctrl_flow_update *fup, *prev; > + LIST_FOR_EACH_REVERSE_SAFE (fup, prev, list_node, &flow_updates) { > + if (nb_cfg < fup->nb_cfg) { > + /* This ofctrl_flow_update is for a configuration later > than > + * 'nb_cfg'. This should not normally happen, because it > means > + * that 'nb_cfg' in the SB_Global table of the southbound > + * database decreased, and it should normally be > monotonically > + * increasing. */ > Would this also get hit if nb_cfg overflows? That would sure be a *lot* of transactions, though ... -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev