[ovs-dev] [RFC v2] Document process for compatibility between OVS and OVN.

Ben Pfaff blp at ovn.org
Thu Sep 12 20:21:27 UTC 2019


On Thu, Sep 12, 2019 at 04:06:14PM -0400, Mark Michelson wrote:
> On 9/12/19 3:25 PM, Ben Pfaff wrote:
> > It's possible that we could introduce features for logical flows that
> > allow different behavior based on whether a given node supports a
> > particular feature.  I've thought about this in the past, but it
> > didn't become necessary yet.
> 
> I'm curious how this would operate. I tend to think of logical flows as
> describing a feature at a high level. It's then up to ovn-controller to
> translate this as appropriate. So I would think the logical flow would not
> be interested in what the node's datapath supports, since the node is free
> to translate the logical flow as it sees fit.
> 
> I guess this would be useful if the presence of a feature on a node might
> affect subsequent logical flows beyond the current one being evaluated,
> though.

The kind of compatibility I have in mind would cover two kinds of
situations:

1. If ovn-northd has to deal with cases where ovn-controller might not
   be up-to-date on some nodes, then it might need to enable some
   features conditionally.  In the upgrade order we originally
   prescribed, this will not happen because ovn-controller is upgraded
   first, but I remember hearing that there is some kind of pressure
   to support upgrading in the opposite order.

2. If ovn-controller has to deal with cases where OVS or its datapath
   might not be up-to-date in some important way, and there's some
   kind of fallback that can be implemented for older versions.

I envision this as being the moral equivalent of #ifdefs for logical
flows.

It's better if it's not needed.


More information about the dev mailing list