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

Reply via email to