[ovs-dev] [ovs-discuss] Geneve remote_ip as flow for OVN hosts

[Venugopal Iyer]

________________________________________
From: Ben Pfaff <blp at ovn.org>
Sent: Thursday, February 7, 2019 6:53 PM
To: Venugopal Iyer
Cc: Guru Shetty; Leonid Grossman; dev at 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.
-----------------------------------------------------------------------------------