On Thu, Feb 07, 2019 at 08:10:48PM +0000, Venugopal Iyer wrote: > > Also, as I mentioned the changes will mean that the ovn-controller will > > need the ovn-central > > to be updated to the changed version as well (i.e. if someone just installs > > ovs and ovn-host > > s/he can't expect it to be backward compatible with the older version of > > ovn-sb). Is that > > acceptable? > > That's not what we usually want. The OVN upgrade process expects the > HVs to be upgraded before the central nodes. If that breaks things, > especially in the case where the deployment is only using a single > interface per HV, it's a problem. > > What would it take to retain compatibility? > > <vi> That is possible; I have committed the changes to the repo[1]. I have > tested > <vi> ovn-host upgrade with these changes against an OVN central based on 2.9 > <vi> (without m-vtep changes). > <vi> Initially, I was planning to bind the port to an encap even if > "encap-ip" external_ids > <vi> is not configured; so when the updated ovn-host comes up, it'll try to > bind the > <vi> port to an encap and the transaction failure caused the port bindings to > fail. Implicit > <vi> binding is not needed, probably not preferred either. So, an updated > ovn-host > <vi> should work with a prev version of SB, however, the OVN central will be > <vi> updated too, right? Else, if one configures "encap-ip" subsequently on > an updated > <vi> ovn-host to work with m-vtep, we'll hit the same issue. > <vi> [1]https://github.com/iyervl/nv-ovs
Of course we want users to upgrade the entire system. We just need to make sure that it's possible to upgrade one piece at a time in an order that ensures that the system isn't broken by a partial upgrade. The specified order for OVN is to upgrade the HVs first, then the central node. (Although apparently some people want to do it in the other order, which is currently a problem.) _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
