Sorry, Ben, for the delay, just wanted to test out the compatibility, please see response inline prefixed with <vi>
Let me know if you have further questions. thanks, -venu ________________________________________ From: Ben Pfaff <[email protected]> Sent: Wednesday, February 6, 2019 10:15 AM To: Venugopal Iyer Cc: Guru Shetty; Leonid Grossman; [email protected] Subject: Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts It looks like we fell off ovs-dev somehow. I've added it back. On Wed, Feb 06, 2019 at 05:50:39PM +0000, Venugopal Iyer wrote: > Thanks, Ben! > > I missed and {} for an if; have fixed it; thanks for catching it! > > As for the TODOS: > - ovn/controller/chassis.c was something I just wanted to check, but not > needed, so have > removed it. > > - ovn/controller/physical.c is not relevant, so removed it. > > - ovn/utitilities/ovnn-sbctl.c was to add a cmd to bind a encap to a port. I > am not > planning to do that now since it will work even if we don't explicitly bind > (it will select > the preferred encap to the chassis it is bound to). If we see a need to > provide a > lsp-encap-bind (or somesuch) we can add it later. Let me know if that works. OK, thanks. > BTW, I wanted to check if it is possible to rename "ovn-chassis-id" to > "ovn-tunnel-id" > since that is more appropriate. Not sure if that'll cause any grief to > existing tools/scripts > that specifically look for ovn-chassis-id. Good names are important but we don't want to change names if it causes compatibility problems. However... > 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 > I haven't updated the test suite (to add a couple of tests for m-vtep); i.e > to make sure the > port binding is done correctly. What is the process to proceed with > integrating the changes; > is it required that the tests be committed at the same time the changes are? > > I have pushed the changes to https://github.com/iyervl/nv-ovs after cleaning > up the > comments and adding the missing {}. > > Once the changes look fine, I'll squash the commits and also add the detailed > commit > and let you know. > > thanks for your time and help! > > -venu > > ________________________________________ > From: Ben Pfaff <[email protected]> > Sent: Tuesday, February 5, 2019 12:55 PM > To: Venugopal Iyer > Cc: Guru Shetty; Leonid Grossman > Subject: Re: [ovs-discuss] [ovs-dev] Geneve remote_ip as flow for OVN hosts > > Thanks. > > I looked over this again now. There are multiple TODO items still in > it. Do you intend to fix them? > > The version in ovn-sb.ovsschema should be updated, probably to 2.1.0. > > I noticed one missing {} around an 'if' block. > > I'd appreciate a detailed commit message for the series (which I imagine > will ultimately be squashed into one patch for commit). > > Thanks again! ----------------------------------------------------------------------------------- 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 [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
