________________________________________ From: Ben Pfaff <b...@ovn.org> Sent: Thursday, February 7, 2019 6:53 PM To: Venugopal Iyer Cc: Guru Shetty; Leonid Grossman; d...@openvswitch.org Subject: Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts
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.) <vi> Thanks, I have updated the repo to squash all the commits and added a high <vi> level commit message. Please let me know if the message is helpful and/or if <vi> there are some best practices that I should follow. FYI, branch mvtep-br <vi> @ https://github.com/iyervl/nv-ovs thanks! -venu ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
