Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Tue, Nov 26, 2019 at 9:54 PM Numan Siddique wrote: > > > > On Wed, Nov 27, 2019, 7:25 AM Han Zhou wrote: >> >> On Sun, Nov 17, 2019 at 10:55 PM Numan Siddique wrote: >> > >> > On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: >> > > >> > > On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: >> > > > >> > > > >> > > > >> > > > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: >> > > >> >> > > >> >> > > >> >> > > >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique >> wrote: >> > > >> > >> > > >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: >> > > >> > > >> > > >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique < num...@ovn.org> >> > > wrote: >> > > >> > > > >> > > >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: >> > > >> > > > > >> > > >> > > > > The series supports interconnecting multiple OVN deployments >> > > (e.g. >> > > >> > > located at >> > > >> > > > > multiple data centers) through logical routers connected with >> > > tansit >> > > >> > > logical >> > > >> > > > > switches with overlay tunnels, managed through OVN control >> > > plane. See >> > > >> > > the >> > > >> > > > > ovn-architecture.rst document updates for more details, and >> find >> > > the >> > > >> > > > > instructions in >> Documentation/tutorials/ovn-interconnection.rst. >> > > >> > > > > >> > > >> > > > > Han Zhou (13): >> > > >> > > > > ovn-architecture: Add documentation for OVN interconnection >> > > feature. >> > > >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. >> > > >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. >> > > >> > > > > ovn-ic: Interconnection controller with AZ registeration. >> > > >> > > > > ovn-northd.c: Refactor allocate_tnlid. >> > > >> > > > > ovn-ic: Transit switch controller. >> > > >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. >> > > >> > > > > ovn-ic: Interconnection gateway controller. >> > > >> > > > > ovn-ic: Interconnection port controller. >> > > >> > > > > ovn.at: e2e test for OVN interconnection. >> > > >> > > > > ovn-ctl: Refactor to reduce redundant code. >> > > >> > > > > ovn-ctl: Support commands for interconnection. >> > > >> > > > > tutorial: Add tutorial for OVN Interconnection. >> > > >> > > > > >> > > >> > > > >> > > >> > > > Hi Han, >> > > >> > > > >> > > >> > > > Thanks for working on this feature. It's an interesting use >> case. >> > > >> > > > >> > > >> > > > I had a quick look at all the patches. >> > > >> > > > >> > > >> > > >> > > >> > > Numan, thanks a lot for the thorough review! Please see my >> response >> > > inlined. >> > > >> > > >> > > >> > > > I have few comments >> > > >> > > > >> > > >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema >> (and >> > > the >> > > >> > > > same for ovn-isb). >> > > >> > > > The DB name is - OVN_IC_Northbound. So it would make sense >> to >> > > have >> > > >> > > > - ovn-ic-nb.ovsschema >> > > >> > > > I would also suggest to rename the utilities to >> ovn-ic-nbctl >> > > and >> > > >> > > > ovn-ic-sbctl. >> > > >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. >> > > >> > > > >> > > >> > > Sure, I felt not quite convenient with two dashes in a command >> name. >> > > I >> > > >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can >> > > change it. >> > > >> > > >> > > >> > > > 2. ovn-ic service writes to interconnect south db, ovn north >> db and >> > > >> > > > ovn south db. Writing to ic south db and >> > > >> > > > ovn north db is fine. But it seems a little odd for ovn-ic >> to >> > > >> > > > write to south db. From what I understand it writes >> > > >> > > > to south db for 3 purposes >> > > >> > > > a. Updating the tunnel_key column of datapath_binding >> > > >> > > > representing the transit switch >> > > >> > > > b. Updating the key column of port_binding representing >> the >> > > >> > > > logical router port connecting to the transit switch. >> > > >> > > > c. Creating chassis rows for remote gateway chassis. >> > > >> > > > >> > > >> > > >I think it's better if ovn-ic can delegate all these to >> > > ovn-northd. >> > > >> > > > For (a) and (b), ovn-ic can set the generated tunnel key >> > > >> > > >in the other_config/options column of Logical switch/Logical >> > > switch >> > > >> > > > port. ovn-northd can internally set this value to >> > > >> > > >the south db. >> > > >> > > > >> > > >> > > >For (c), I think its better we add another table - >> > > Remote_Chassis >> > > >> > > > (or some other appropriate name) . ovn-ic will create rows >> > > >> > > >in this table for each remote chassis and ovn-northd will >> create >> > > >> > > > chassis row in south db. >> > > >> > > >We already have Gateway_Chassis table in North db. So I >> think >> > > it's >> > > >> > > > fine if we add Remote_Chassis table. The only odd thing >> > > >> > > >would be is to store the encap details in North db. >> > > >> >
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Wed, Nov 27, 2019, 7:25 AM Han Zhou wrote: > On Sun, Nov 17, 2019 at 10:55 PM Numan Siddique wrote: > > > > On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: > > > > > > On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: > > > > > > > > > > > > > > > > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: > > > >> > > > >> > > > >> > > > >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique > wrote: > > > >> > > > > >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: > > > >> > > > > > >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique > > > > wrote: > > > >> > > > > > > >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou > wrote: > > > >> > > > > > > > >> > > > > The series supports interconnecting multiple OVN deployments > > > (e.g. > > > >> > > located at > > > >> > > > > multiple data centers) through logical routers connected > with > > > tansit > > > >> > > logical > > > >> > > > > switches with overlay tunnels, managed through OVN control > > > plane. See > > > >> > > the > > > >> > > > > ovn-architecture.rst document updates for more details, and > find > > > the > > > >> > > > > instructions in > Documentation/tutorials/ovn-interconnection.rst. > > > >> > > > > > > > >> > > > > Han Zhou (13): > > > >> > > > > ovn-architecture: Add documentation for OVN > interconnection > > > feature. > > > >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. > > > >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. > > > >> > > > > ovn-ic: Interconnection controller with AZ registeration. > > > >> > > > > ovn-northd.c: Refactor allocate_tnlid. > > > >> > > > > ovn-ic: Transit switch controller. > > > >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. > > > >> > > > > ovn-ic: Interconnection gateway controller. > > > >> > > > > ovn-ic: Interconnection port controller. > > > >> > > > > ovn.at: e2e test for OVN interconnection. > > > >> > > > > ovn-ctl: Refactor to reduce redundant code. > > > >> > > > > ovn-ctl: Support commands for interconnection. > > > >> > > > > tutorial: Add tutorial for OVN Interconnection. > > > >> > > > > > > > >> > > > > > > >> > > > Hi Han, > > > >> > > > > > > >> > > > Thanks for working on this feature. It's an interesting use > case. > > > >> > > > > > > >> > > > I had a quick look at all the patches. > > > >> > > > > > > >> > > > > > >> > > Numan, thanks a lot for the thorough review! Please see my > response > > > inlined. > > > >> > > > > > >> > > > I have few comments > > > >> > > > > > > >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema > (and > > > the > > > >> > > > same for ovn-isb). > > > >> > > > The DB name is - OVN_IC_Northbound. So it would make sense > to > > > have > > > >> > > > - ovn-ic-nb.ovsschema > > > >> > > > I would also suggest to rename the utilities to > ovn-ic-nbctl > > > and > > > >> > > > ovn-ic-sbctl. > > > >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. > > > >> > > > > > > >> > > Sure, I felt not quite convenient with two dashes in a command > name. > > > I > > > >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can > > > change it. > > > >> > > > > > >> > > > 2. ovn-ic service writes to interconnect south db, ovn north > db and > > > >> > > > ovn south db. Writing to ic south db and > > > >> > > > ovn north db is fine. But it seems a little odd for ovn-ic > to > > > >> > > > write to south db. From what I understand it writes > > > >> > > > to south db for 3 purposes > > > >> > > > a. Updating the tunnel_key column of datapath_binding > > > >> > > > representing the transit switch > > > >> > > > b. Updating the key column of port_binding representing > the > > > >> > > > logical router port connecting to the transit switch. > > > >> > > > c. Creating chassis rows for remote gateway chassis. > > > >> > > > > > > >> > > >I think it's better if ovn-ic can delegate all these to > > > ovn-northd. > > > >> > > > For (a) and (b), ovn-ic can set the generated tunnel key > > > >> > > >in the other_config/options column of Logical > switch/Logical > > > switch > > > >> > > > port. ovn-northd can internally set this value to > > > >> > > >the south db. > > > >> > > > > > > >> > > >For (c), I think its better we add another table - > > > Remote_Chassis > > > >> > > > (or some other appropriate name) . ovn-ic will create rows > > > >> > > >in this table for each remote chassis and ovn-northd will > create > > > >> > > > chassis row in south db. > > > >> > > >We already have Gateway_Chassis table in North db. So I > think > > > it's > > > >> > > > fine if we add Remote_Chassis table. The only odd thing > > > >> > > >would be is to store the encap details in North db. > > > >> > > > > > > >> > > >With this, ovn-ic, doesn't need to worry about syncing > between > > > >> > > > interconnect south db and ovn south db. In my opinion ovn-ic > > > >> > > >should act
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Sun, Nov 17, 2019 at 10:55 PM Numan Siddique wrote: > > On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: > > > > On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: > > > > > > > > > > > > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: > > >> > > >> > > >> > > >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: > > >> > > > >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: > > >> > > > > >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique > > wrote: > > >> > > > > > >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: > > >> > > > > > > >> > > > > The series supports interconnecting multiple OVN deployments > > (e.g. > > >> > > located at > > >> > > > > multiple data centers) through logical routers connected with > > tansit > > >> > > logical > > >> > > > > switches with overlay tunnels, managed through OVN control > > plane. See > > >> > > the > > >> > > > > ovn-architecture.rst document updates for more details, and find > > the > > >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. > > >> > > > > > > >> > > > > Han Zhou (13): > > >> > > > > ovn-architecture: Add documentation for OVN interconnection > > feature. > > >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. > > >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. > > >> > > > > ovn-ic: Interconnection controller with AZ registeration. > > >> > > > > ovn-northd.c: Refactor allocate_tnlid. > > >> > > > > ovn-ic: Transit switch controller. > > >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. > > >> > > > > ovn-ic: Interconnection gateway controller. > > >> > > > > ovn-ic: Interconnection port controller. > > >> > > > > ovn.at: e2e test for OVN interconnection. > > >> > > > > ovn-ctl: Refactor to reduce redundant code. > > >> > > > > ovn-ctl: Support commands for interconnection. > > >> > > > > tutorial: Add tutorial for OVN Interconnection. > > >> > > > > > > >> > > > > > >> > > > Hi Han, > > >> > > > > > >> > > > Thanks for working on this feature. It's an interesting use case. > > >> > > > > > >> > > > I had a quick look at all the patches. > > >> > > > > > >> > > > > >> > > Numan, thanks a lot for the thorough review! Please see my response > > inlined. > > >> > > > > >> > > > I have few comments > > >> > > > > > >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and > > the > > >> > > > same for ovn-isb). > > >> > > > The DB name is - OVN_IC_Northbound. So it would make sense to > > have > > >> > > > - ovn-ic-nb.ovsschema > > >> > > > I would also suggest to rename the utilities to ovn-ic-nbctl > > and > > >> > > > ovn-ic-sbctl. > > >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. > > >> > > > > > >> > > Sure, I felt not quite convenient with two dashes in a command name. > > I > > >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can > > change it. > > >> > > > > >> > > > 2. ovn-ic service writes to interconnect south db, ovn north db and > > >> > > > ovn south db. Writing to ic south db and > > >> > > > ovn north db is fine. But it seems a little odd for ovn-ic to > > >> > > > write to south db. From what I understand it writes > > >> > > > to south db for 3 purposes > > >> > > > a. Updating the tunnel_key column of datapath_binding > > >> > > > representing the transit switch > > >> > > > b. Updating the key column of port_binding representing the > > >> > > > logical router port connecting to the transit switch. > > >> > > > c. Creating chassis rows for remote gateway chassis. > > >> > > > > > >> > > >I think it's better if ovn-ic can delegate all these to > > ovn-northd. > > >> > > > For (a) and (b), ovn-ic can set the generated tunnel key > > >> > > >in the other_config/options column of Logical switch/Logical > > switch > > >> > > > port. ovn-northd can internally set this value to > > >> > > >the south db. > > >> > > > > > >> > > >For (c), I think its better we add another table - > > Remote_Chassis > > >> > > > (or some other appropriate name) . ovn-ic will create rows > > >> > > >in this table for each remote chassis and ovn-northd will create > > >> > > > chassis row in south db. > > >> > > >We already have Gateway_Chassis table in North db. So I think > > it's > > >> > > > fine if we add Remote_Chassis table. The only odd thing > > >> > > >would be is to store the encap details in North db. > > >> > > > > > >> > > >With this, ovn-ic, doesn't need to worry about syncing between > > >> > > > interconnect south db and ovn south db. In my opinion ovn-ic > > >> > > >should act more like CMS to each availability zone and hence > > should > > >> > > > not do any write transactions to the south db. > > >> > > > > > >> > > > Any concerns with this proposed approach ? > > >> > > > > > >> > > We could avoid ovn-ic writing directly to SB with some extra logic in > > >> > > northd, but I
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
Get it. Thanks Han. At 2019-11-20 11:51:17, "Han Zhou" wrote: Hi Yun, This feature in OVN doesn't require or put limit on the CMS systems such as Neutron, or kubernetes. To utilize this feature from CMS system, the CMS integration may be needed, e.g. add support in networking-ovn Neutron plugin or networking-ovn k8s plugin. However, the scenario you described that multiple AZs managed by a single global Neutron is not directly related to this feature. The first thing is to add support to networking-ovn so that a single neutron can manage multiple OVN deployments, if that is a realistic use case. That's needed even without this ovn-interconnection feature. However, it seems Neutron interface doesn't have the AZ concept (as far as I know, unless it is added in recent releases), so it seems not straightforward to support such feature in networking-ovn. To support it, I guess you will need something like OVN control plane federation, which is a completely different problem from the one that is going to solved by the ovn-interconnection feature. Thanks, Han On Tue, Nov 19, 2019 at 7:30 PM taoyunupt wrote: Hi,Han,Numan, If I am not mistake, each AZ(OVN deployment) must have a corresponding networking-ovn(neurton). But if we want to have a global neutron above AZ, that is, multi AZ(OVN deployment) is controlled by one neutron, this would be not work? Am I right ? Did you consider this situation? Thanks, Yun At 2019-11-18 14:55:26, "Numan Siddique" wrote: >On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: >> >> On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: >> > >> > >> > >> > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: >> >> >> >> >> >> >> >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: >> >> > >> >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: >> >> > > >> >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique >> wrote: >> >> > > > >> >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: >> >> > > > > >> >> > > > > The series supports interconnecting multiple OVN deployments >> (e.g. >> >> > > located at >> >> > > > > multiple data centers) through logical routers connected with >> tansit >> >> > > logical >> >> > > > > switches with overlay tunnels, managed through OVN control >> plane. See >> >> > > the >> >> > > > > ovn-architecture.rst document updates for more details, and find >> the >> >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. >> >> > > > > >> >> > > > > Han Zhou (13): >> >> > > > > ovn-architecture: Add documentation for OVN interconnection >> feature. >> >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. >> >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. >> >> > > > > ovn-ic: Interconnection controller with AZ registeration. >> >> > > > > ovn-northd.c: Refactor allocate_tnlid. >> >> > > > > ovn-ic: Transit switch controller. >> >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. >> >> > > > > ovn-ic: Interconnection gateway controller. >> >> > > > > ovn-ic: Interconnection port controller. >> >> > > > > ovn.at: e2e test for OVN interconnection. >> >> > > > > ovn-ctl: Refactor to reduce redundant code. >> >> > > > > ovn-ctl: Support commands for interconnection. >> >> > > > > tutorial: Add tutorial for OVN Interconnection. >> >> > > > > >> >> > > > >> >> > > > Hi Han, >> >> > > > >> >> > > > Thanks for working on this feature. It's an interesting use case. >> >> > > > >> >> > > > I had a quick look at all the patches. >> >> > > > >> >> > > >> >> > > Numan, thanks a lot for the thorough review! Please see my response >> inlined. >> >> > > >> >> > > > I have few comments >> >> > > > >> >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and >> the >> >> > > > same for ovn-isb). >> >> > > > The DB name is - OVN_IC_Northbound. So it would make sense to >> have >> >> > > > - ovn-ic-nb.ovsschema >> >> > > > I would also suggest to rename the utilities to ovn-ic-nbctl >> and >> >> > > > ovn-ic-sbctl. >> >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. >> >> > > > >> >> > > Sure, I felt not quite convenient with two dashes in a command name. >> I >> >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can >> change it. >> >> > > >> >> > > > 2. ovn-ic service writes to interconnect south db, ovn north db and >> >> > > > ovn south db. Writing to ic south db and >> >> > > > ovn north db is fine. But it seems a little odd for ovn-ic to >> >> > > > write to south db. From what I understand it writes >> >> > > > to south db for 3 purposes >> >> > > > a. Updating the tunnel_key column of datapath_binding >> >> > > > representing the transit switch >> >> > > > b. Updating the key column of port_binding representing the >> >> > > > logical router port connecting to the transit switch. >> >> > > > c. Creating chassis rows for remote gateway
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
Hi,Han,Numan, If I am not mistake, each AZ(OVN deployment) must have a corresponding networking-ovn(neurton). But if we want to have a global neutron above AZ, that is, multi AZ(OVN deployment) is controlled by one neutron, this would be not work? Am I right ? Did you consider this situation? Thanks, Yun At 2019-11-18 14:55:26, "Numan Siddique" wrote: >On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: >> >> On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: >> > >> > >> > >> > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: >> >> >> >> >> >> >> >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: >> >> > >> >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: >> >> > > >> >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique >> wrote: >> >> > > > >> >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: >> >> > > > > >> >> > > > > The series supports interconnecting multiple OVN deployments >> (e.g. >> >> > > located at >> >> > > > > multiple data centers) through logical routers connected with >> tansit >> >> > > logical >> >> > > > > switches with overlay tunnels, managed through OVN control >> plane. See >> >> > > the >> >> > > > > ovn-architecture.rst document updates for more details, and find >> the >> >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. >> >> > > > > >> >> > > > > Han Zhou (13): >> >> > > > > ovn-architecture: Add documentation for OVN interconnection >> feature. >> >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. >> >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. >> >> > > > > ovn-ic: Interconnection controller with AZ registeration. >> >> > > > > ovn-northd.c: Refactor allocate_tnlid. >> >> > > > > ovn-ic: Transit switch controller. >> >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. >> >> > > > > ovn-ic: Interconnection gateway controller. >> >> > > > > ovn-ic: Interconnection port controller. >> >> > > > > ovn.at: e2e test for OVN interconnection. >> >> > > > > ovn-ctl: Refactor to reduce redundant code. >> >> > > > > ovn-ctl: Support commands for interconnection. >> >> > > > > tutorial: Add tutorial for OVN Interconnection. >> >> > > > > >> >> > > > >> >> > > > Hi Han, >> >> > > > >> >> > > > Thanks for working on this feature. It's an interesting use case. >> >> > > > >> >> > > > I had a quick look at all the patches. >> >> > > > >> >> > > >> >> > > Numan, thanks a lot for the thorough review! Please see my response >> inlined. >> >> > > >> >> > > > I have few comments >> >> > > > >> >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and >> the >> >> > > > same for ovn-isb). >> >> > > > The DB name is - OVN_IC_Northbound. So it would make sense to >> have >> >> > > > - ovn-ic-nb.ovsschema >> >> > > > I would also suggest to rename the utilities to ovn-ic-nbctl >> and >> >> > > > ovn-ic-sbctl. >> >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. >> >> > > > >> >> > > Sure, I felt not quite convenient with two dashes in a command name. >> I >> >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can >> change it. >> >> > > >> >> > > > 2. ovn-ic service writes to interconnect south db, ovn north db and >> >> > > > ovn south db. Writing to ic south db and >> >> > > > ovn north db is fine. But it seems a little odd for ovn-ic to >> >> > > > write to south db. From what I understand it writes >> >> > > > to south db for 3 purposes >> >> > > > a. Updating the tunnel_key column of datapath_binding >> >> > > > representing the transit switch >> >> > > > b. Updating the key column of port_binding representing the >> >> > > > logical router port connecting to the transit switch. >> >> > > > c. Creating chassis rows for remote gateway chassis. >> >> > > > >> >> > > >I think it's better if ovn-ic can delegate all these to >> ovn-northd. >> >> > > > For (a) and (b), ovn-ic can set the generated tunnel key >> >> > > >in the other_config/options column of Logical switch/Logical >> switch >> >> > > > port. ovn-northd can internally set this value to >> >> > > >the south db. >> >> > > > >> >> > > >For (c), I think its better we add another table - >> Remote_Chassis >> >> > > > (or some other appropriate name) . ovn-ic will create rows >> >> > > >in this table for each remote chassis and ovn-northd will create >> >> > > > chassis row in south db. >> >> > > >We already have Gateway_Chassis table in North db. So I think >> it's >> >> > > > fine if we add Remote_Chassis table. The only odd thing >> >> > > >would be is to store the encap details in North db. >> >> > > > >> >> > > >With this, ovn-ic, doesn't need to worry about syncing between >> >> > > > interconnect south db and ovn south db. In my opinion ovn-ic >> >> > > >should act more like CMS to each availability zone and hence >> should >> >> > > > not do any write transactions to
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
Hi Yun, This feature in OVN doesn't require or put limit on the CMS systems such as Neutron, or kubernetes. To utilize this feature from CMS system, the CMS integration may be needed, e.g. add support in networking-ovn Neutron plugin or networking-ovn k8s plugin. However, the scenario you described that multiple AZs managed by a single global Neutron is not directly related to this feature. The first thing is to add support to networking-ovn so that a single neutron can manage multiple OVN deployments, if that is a realistic use case. That's needed even without this ovn-interconnection feature. However, it seems Neutron interface doesn't have the AZ concept (as far as I know, unless it is added in recent releases), so it seems not straightforward to support such feature in networking-ovn. To support it, I guess you will need something like OVN control plane federation, which is a completely different problem from the one that is going to solved by the ovn-interconnection feature. Thanks, Han On Tue, Nov 19, 2019 at 7:30 PM taoyunupt wrote: > > Hi,Han,Numan, > If I am not mistake, each AZ(OVN deployment) must have a corresponding > networking-ovn(neurton). But if we want to have a global neutron above AZ, > that is, multi AZ(OVN deployment) is controlled by one neutron, this would > be not work? Am I right ? Did you consider this situation? > > Thanks, > Yun > > > > > At 2019-11-18 14:55:26, "Numan Siddique" wrote: > >On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: > >> > >> On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: > >> > > >> > > >> > > >> > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: > >> >> > >> >> > >> >> > >> >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: > >> >> > > >> >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: > >> >> > > > >> >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique > >> wrote: > >> >> > > > > >> >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: > >> >> > > > > > >> >> > > > > The series supports interconnecting multiple OVN deployments > >> (e.g. > >> >> > > located at > >> >> > > > > multiple data centers) through logical routers connected with > >> tansit > >> >> > > logical > >> >> > > > > switches with overlay tunnels, managed through OVN control > >> plane. See > >> >> > > the > >> >> > > > > ovn-architecture.rst document updates for more details, and find > >> the > >> >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. > >> >> > > > > > >> >> > > > > Han Zhou (13): > >> >> > > > > ovn-architecture: Add documentation for OVN interconnection > >> feature. > >> >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. > >> >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. > >> >> > > > > ovn-ic: Interconnection controller with AZ registeration. > >> >> > > > > ovn-northd.c: Refactor allocate_tnlid. > >> >> > > > > ovn-ic: Transit switch controller. > >> >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. > >> >> > > > > ovn-ic: Interconnection gateway controller. > >> >> > > > > ovn-ic: Interconnection port controller. > >> >> > > > > ovn.at: e2e test for OVN interconnection. > >> >> > > > > ovn-ctl: Refactor to reduce redundant code. > >> >> > > > > ovn-ctl: Support commands for interconnection. > >> >> > > > > tutorial: Add tutorial for OVN Interconnection. > >> >> > > > > > >> >> > > > > >> >> > > > Hi Han, > >> >> > > > > >> >> > > > Thanks for working on this feature. It's an interesting use case. > >> >> > > > > >> >> > > > I had a quick look at all the patches. > >> >> > > > > >> >> > > > >> >> > > Numan, thanks a lot for the thorough review! Please see my response > >> inlined. > >> >> > > > >> >> > > > I have few comments > >> >> > > > > >> >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and > >> the > >> >> > > > same for ovn-isb). > >> >> > > > The DB name is - OVN_IC_Northbound. So it would make sense to > >> have > >> >> > > > - ovn-ic-nb.ovsschema > >> >> > > > I would also suggest to rename the utilities to ovn-ic-nbctl > >> and > >> >> > > > ovn-ic-sbctl. > >> >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. > >> >> > > > > >> >> > > Sure, I felt not quite convenient with two dashes in a command name. > >> I > >> >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can > >> change it. > >> >> > > > >> >> > > > 2. ovn-ic service writes to interconnect south db, ovn north db > >> >> > > > and > >> >> > > > ovn south db. Writing to ic south db and > >> >> > > > ovn north db is fine. But it seems a little odd for ovn-ic to > >> >> > > > write to south db. From what I understand it writes > >> >> > > > to south db for 3 purposes > >> >> > > > a. Updating the tunnel_key column of datapath_binding > >> >> > > > representing the transit switch > >> >> > > > b. Updating the key column of port_binding representing the > >> >> > > >
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Mon, Nov 18, 2019 at 8:22 AM Han Zhou wrote: > > On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: > > > > > > > > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: > >> > >> > >> > >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: > >> > > >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: > >> > > > >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique > wrote: > >> > > > > >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: > >> > > > > > >> > > > > The series supports interconnecting multiple OVN deployments > (e.g. > >> > > located at > >> > > > > multiple data centers) through logical routers connected with > tansit > >> > > logical > >> > > > > switches with overlay tunnels, managed through OVN control > plane. See > >> > > the > >> > > > > ovn-architecture.rst document updates for more details, and find > the > >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. > >> > > > > > >> > > > > Han Zhou (13): > >> > > > > ovn-architecture: Add documentation for OVN interconnection > feature. > >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. > >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. > >> > > > > ovn-ic: Interconnection controller with AZ registeration. > >> > > > > ovn-northd.c: Refactor allocate_tnlid. > >> > > > > ovn-ic: Transit switch controller. > >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. > >> > > > > ovn-ic: Interconnection gateway controller. > >> > > > > ovn-ic: Interconnection port controller. > >> > > > > ovn.at: e2e test for OVN interconnection. > >> > > > > ovn-ctl: Refactor to reduce redundant code. > >> > > > > ovn-ctl: Support commands for interconnection. > >> > > > > tutorial: Add tutorial for OVN Interconnection. > >> > > > > > >> > > > > >> > > > Hi Han, > >> > > > > >> > > > Thanks for working on this feature. It's an interesting use case. > >> > > > > >> > > > I had a quick look at all the patches. > >> > > > > >> > > > >> > > Numan, thanks a lot for the thorough review! Please see my response > inlined. > >> > > > >> > > > I have few comments > >> > > > > >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and > the > >> > > > same for ovn-isb). > >> > > > The DB name is - OVN_IC_Northbound. So it would make sense to > have > >> > > > - ovn-ic-nb.ovsschema > >> > > > I would also suggest to rename the utilities to ovn-ic-nbctl > and > >> > > > ovn-ic-sbctl. > >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. > >> > > > > >> > > Sure, I felt not quite convenient with two dashes in a command name. > I > >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can > change it. > >> > > > >> > > > 2. ovn-ic service writes to interconnect south db, ovn north db and > >> > > > ovn south db. Writing to ic south db and > >> > > > ovn north db is fine. But it seems a little odd for ovn-ic to > >> > > > write to south db. From what I understand it writes > >> > > > to south db for 3 purposes > >> > > > a. Updating the tunnel_key column of datapath_binding > >> > > > representing the transit switch > >> > > > b. Updating the key column of port_binding representing the > >> > > > logical router port connecting to the transit switch. > >> > > > c. Creating chassis rows for remote gateway chassis. > >> > > > > >> > > >I think it's better if ovn-ic can delegate all these to > ovn-northd. > >> > > > For (a) and (b), ovn-ic can set the generated tunnel key > >> > > >in the other_config/options column of Logical switch/Logical > switch > >> > > > port. ovn-northd can internally set this value to > >> > > >the south db. > >> > > > > >> > > >For (c), I think its better we add another table - > Remote_Chassis > >> > > > (or some other appropriate name) . ovn-ic will create rows > >> > > >in this table for each remote chassis and ovn-northd will create > >> > > > chassis row in south db. > >> > > >We already have Gateway_Chassis table in North db. So I think > it's > >> > > > fine if we add Remote_Chassis table. The only odd thing > >> > > >would be is to store the encap details in North db. > >> > > > > >> > > >With this, ovn-ic, doesn't need to worry about syncing between > >> > > > interconnect south db and ovn south db. In my opinion ovn-ic > >> > > >should act more like CMS to each availability zone and hence > should > >> > > > not do any write transactions to the south db. > >> > > > > >> > > > Any concerns with this proposed approach ? > >> > > > > >> > > We could avoid ovn-ic writing directly to SB with some extra logic in > >> > > northd, but I don't see any problem for ovn-ic to update SB > directly. First > >> > > of all, we have hypervisors creating and updating SB directly for > Chassis > >> > > and Encap records. The design here is that ovn-ic updates Chassis > and Encap > >> > > on behalf of remote gateway nodes, which I
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Sat, Nov 16, 2019 at 4:03 AM Numan Siddique wrote: > > > > On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: >> >> >> >> On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: >> > >> > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: >> > > >> > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique wrote: >> > > > >> > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: >> > > > > >> > > > > The series supports interconnecting multiple OVN deployments (e.g. >> > > located at >> > > > > multiple data centers) through logical routers connected with tansit >> > > logical >> > > > > switches with overlay tunnels, managed through OVN control plane. See >> > > the >> > > > > ovn-architecture.rst document updates for more details, and find the >> > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. >> > > > > >> > > > > Han Zhou (13): >> > > > > ovn-architecture: Add documentation for OVN interconnection feature. >> > > > > ovn-inb: Interconnection northbound DB schema and CLI. >> > > > > ovn-isb: Interconnection southbound DB schema and CLI. >> > > > > ovn-ic: Interconnection controller with AZ registeration. >> > > > > ovn-northd.c: Refactor allocate_tnlid. >> > > > > ovn-ic: Transit switch controller. >> > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. >> > > > > ovn-ic: Interconnection gateway controller. >> > > > > ovn-ic: Interconnection port controller. >> > > > > ovn.at: e2e test for OVN interconnection. >> > > > > ovn-ctl: Refactor to reduce redundant code. >> > > > > ovn-ctl: Support commands for interconnection. >> > > > > tutorial: Add tutorial for OVN Interconnection. >> > > > > >> > > > >> > > > Hi Han, >> > > > >> > > > Thanks for working on this feature. It's an interesting use case. >> > > > >> > > > I had a quick look at all the patches. >> > > > >> > > >> > > Numan, thanks a lot for the thorough review! Please see my response inlined. >> > > >> > > > I have few comments >> > > > >> > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and the >> > > > same for ovn-isb). >> > > > The DB name is - OVN_IC_Northbound. So it would make sense to have >> > > > - ovn-ic-nb.ovsschema >> > > > I would also suggest to rename the utilities to ovn-ic-nbctl and >> > > > ovn-ic-sbctl. >> > > > With ovn-inbctl/ovn-isbctl, it is really confusing. >> > > > >> > > Sure, I felt not quite convenient with two dashes in a command name. I >> > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can change it. >> > > >> > > > 2. ovn-ic service writes to interconnect south db, ovn north db and >> > > > ovn south db. Writing to ic south db and >> > > > ovn north db is fine. But it seems a little odd for ovn-ic to >> > > > write to south db. From what I understand it writes >> > > > to south db for 3 purposes >> > > > a. Updating the tunnel_key column of datapath_binding >> > > > representing the transit switch >> > > > b. Updating the key column of port_binding representing the >> > > > logical router port connecting to the transit switch. >> > > > c. Creating chassis rows for remote gateway chassis. >> > > > >> > > >I think it's better if ovn-ic can delegate all these to ovn-northd. >> > > > For (a) and (b), ovn-ic can set the generated tunnel key >> > > >in the other_config/options column of Logical switch/Logical switch >> > > > port. ovn-northd can internally set this value to >> > > >the south db. >> > > > >> > > >For (c), I think its better we add another table - Remote_Chassis >> > > > (or some other appropriate name) . ovn-ic will create rows >> > > >in this table for each remote chassis and ovn-northd will create >> > > > chassis row in south db. >> > > >We already have Gateway_Chassis table in North db. So I think it's >> > > > fine if we add Remote_Chassis table. The only odd thing >> > > >would be is to store the encap details in North db. >> > > > >> > > >With this, ovn-ic, doesn't need to worry about syncing between >> > > > interconnect south db and ovn south db. In my opinion ovn-ic >> > > >should act more like CMS to each availability zone and hence should >> > > > not do any write transactions to the south db. >> > > > >> > > > Any concerns with this proposed approach ? >> > > > >> > > We could avoid ovn-ic writing directly to SB with some extra logic in >> > > northd, but I don't see any problem for ovn-ic to update SB directly. First >> > > of all, we have hypervisors creating and updating SB directly for Chassis >> > > and Encap records. The design here is that ovn-ic updates Chassis and Encap >> > > on behalf of remote gateway nodes, which I think is straightforward and >> > > reasonable. Similarly, port-binding's chassis column is updated the same >> > > way as how hypervisors are updating it. Secondly, for tunnel keys updating, >> > > it may seem graceful to update from northd, since northd is the only client >> > > that
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Fri, Nov 15, 2019 at 1:18 PM Han Zhou wrote: > > > On Thu, Nov 14, 2019 at 10:25 PM Numan Siddique wrote: > > > > On Thu, Nov 14, 2019 at 11:44 PM Han Zhou wrote: > > > > > > On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique > wrote: > > > > > > > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: > > > > > > > > > > The series supports interconnecting multiple OVN deployments (e.g. > > > located at > > > > > multiple data centers) through logical routers connected with > tansit > > > logical > > > > > switches with overlay tunnels, managed through OVN control plane. > See > > > the > > > > > ovn-architecture.rst document updates for more details, and find > the > > > > > instructions in Documentation/tutorials/ovn-interconnection.rst. > > > > > > > > > > Han Zhou (13): > > > > > ovn-architecture: Add documentation for OVN interconnection > feature. > > > > > ovn-inb: Interconnection northbound DB schema and CLI. > > > > > ovn-isb: Interconnection southbound DB schema and CLI. > > > > > ovn-ic: Interconnection controller with AZ registeration. > > > > > ovn-northd.c: Refactor allocate_tnlid. > > > > > ovn-ic: Transit switch controller. > > > > > ovn-sb: Add columns is_interconn and is_remote to Chassis. > > > > > ovn-ic: Interconnection gateway controller. > > > > > ovn-ic: Interconnection port controller. > > > > > ovn.at: e2e test for OVN interconnection. > > > > > ovn-ctl: Refactor to reduce redundant code. > > > > > ovn-ctl: Support commands for interconnection. > > > > > tutorial: Add tutorial for OVN Interconnection. > > > > > > > > > > > > > Hi Han, > > > > > > > > Thanks for working on this feature. It's an interesting use case. > > > > > > > > I had a quick look at all the patches. > > > > > > > > > > Numan, thanks a lot for the thorough review! Please see my response > inlined. > > > > > > > I have few comments > > > > > > > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and the > > > > same for ovn-isb). > > > > The DB name is - OVN_IC_Northbound. So it would make sense to > have > > > > - ovn-ic-nb.ovsschema > > > > I would also suggest to rename the utilities to ovn-ic-nbctl and > > > > ovn-ic-sbctl. > > > > With ovn-inbctl/ovn-isbctl, it is really confusing. > > > > > > > Sure, I felt not quite convenient with two dashes in a command name. I > > > agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can change > it. > > > > > > > 2. ovn-ic service writes to interconnect south db, ovn north db and > > > > ovn south db. Writing to ic south db and > > > > ovn north db is fine. But it seems a little odd for ovn-ic to > > > > write to south db. From what I understand it writes > > > > to south db for 3 purposes > > > > a. Updating the tunnel_key column of datapath_binding > > > > representing the transit switch > > > > b. Updating the key column of port_binding representing the > > > > logical router port connecting to the transit switch. > > > > c. Creating chassis rows for remote gateway chassis. > > > > > > > >I think it's better if ovn-ic can delegate all these to > ovn-northd. > > > > For (a) and (b), ovn-ic can set the generated tunnel key > > > >in the other_config/options column of Logical switch/Logical > switch > > > > port. ovn-northd can internally set this value to > > > >the south db. > > > > > > > >For (c), I think its better we add another table - Remote_Chassis > > > > (or some other appropriate name) . ovn-ic will create rows > > > >in this table for each remote chassis and ovn-northd will create > > > > chassis row in south db. > > > >We already have Gateway_Chassis table in North db. So I think it's > > > > fine if we add Remote_Chassis table. The only odd thing > > > >would be is to store the encap details in North db. > > > > > > > >With this, ovn-ic, doesn't need to worry about syncing between > > > > interconnect south db and ovn south db. In my opinion ovn-ic > > > >should act more like CMS to each availability zone and hence > should > > > > not do any write transactions to the south db. > > > > > > > > Any concerns with this proposed approach ? > > > > > > > We could avoid ovn-ic writing directly to SB with some extra logic in > > > northd, but I don't see any problem for ovn-ic to update SB directly. > First > > > of all, we have hypervisors creating and updating SB directly for > Chassis > > > and Encap records. The design here is that ovn-ic updates Chassis and > Encap > > > on behalf of remote gateway nodes, which I think is straightforward and > > > reasonable. Similarly, port-binding's chassis column is updated the > same > > > way as how hypervisors are updating it. Secondly, for tunnel keys > updating, > > > it may seem graceful to update from northd, since northd is the only > client > > > that updates tunnel keys today, but since ovn-ic is responsible for > > > calculating these keys, and it already has connection to SB, I
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Wed, Nov 13, 2019 at 10:27 AM Numan Siddique wrote: > > On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: > > > > The series supports interconnecting multiple OVN deployments (e.g. located at > > multiple data centers) through logical routers connected with tansit logical > > switches with overlay tunnels, managed through OVN control plane. See the > > ovn-architecture.rst document updates for more details, and find the > > instructions in Documentation/tutorials/ovn-interconnection.rst. > > > > Han Zhou (13): > > ovn-architecture: Add documentation for OVN interconnection feature. > > ovn-inb: Interconnection northbound DB schema and CLI. > > ovn-isb: Interconnection southbound DB schema and CLI. > > ovn-ic: Interconnection controller with AZ registeration. > > ovn-northd.c: Refactor allocate_tnlid. > > ovn-ic: Transit switch controller. > > ovn-sb: Add columns is_interconn and is_remote to Chassis. > > ovn-ic: Interconnection gateway controller. > > ovn-ic: Interconnection port controller. > > ovn.at: e2e test for OVN interconnection. > > ovn-ctl: Refactor to reduce redundant code. > > ovn-ctl: Support commands for interconnection. > > tutorial: Add tutorial for OVN Interconnection. > > > > Hi Han, > > Thanks for working on this feature. It's an interesting use case. > > I had a quick look at all the patches. > Numan, thanks a lot for the thorough review! Please see my response inlined. > I have few comments > > 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and the > same for ovn-isb). > The DB name is - OVN_IC_Northbound. So it would make sense to have > - ovn-ic-nb.ovsschema > I would also suggest to rename the utilities to ovn-ic-nbctl and > ovn-ic-sbctl. > With ovn-inbctl/ovn-isbctl, it is really confusing. > Sure, I felt not quite convenient with two dashes in a command name. I agree that ovn-ic-nbctl and ovn-ic-sbctl are more clear. I can change it. > 2. ovn-ic service writes to interconnect south db, ovn north db and > ovn south db. Writing to ic south db and > ovn north db is fine. But it seems a little odd for ovn-ic to > write to south db. From what I understand it writes > to south db for 3 purposes > a. Updating the tunnel_key column of datapath_binding > representing the transit switch > b. Updating the key column of port_binding representing the > logical router port connecting to the transit switch. > c. Creating chassis rows for remote gateway chassis. > >I think it's better if ovn-ic can delegate all these to ovn-northd. > For (a) and (b), ovn-ic can set the generated tunnel key >in the other_config/options column of Logical switch/Logical switch > port. ovn-northd can internally set this value to >the south db. > >For (c), I think its better we add another table - Remote_Chassis > (or some other appropriate name) . ovn-ic will create rows >in this table for each remote chassis and ovn-northd will create > chassis row in south db. >We already have Gateway_Chassis table in North db. So I think it's > fine if we add Remote_Chassis table. The only odd thing >would be is to store the encap details in North db. > >With this, ovn-ic, doesn't need to worry about syncing between > interconnect south db and ovn south db. In my opinion ovn-ic >should act more like CMS to each availability zone and hence should > not do any write transactions to the south db. > > Any concerns with this proposed approach ? > We could avoid ovn-ic writing directly to SB with some extra logic in northd, but I don't see any problem for ovn-ic to update SB directly. First of all, we have hypervisors creating and updating SB directly for Chassis and Encap records. The design here is that ovn-ic updates Chassis and Encap on behalf of remote gateway nodes, which I think is straightforward and reasonable. Similarly, port-binding's chassis column is updated the same way as how hypervisors are updating it. Secondly, for tunnel keys updating, it may seem graceful to update from northd, since northd is the only client that updates tunnel keys today, but since ovn-ic is responsible for calculating these keys, and it already has connection to SB, I think it is just more natural and efficient to update it directly, to avoid the extra logic and unnecessary latency from northd with another round of computation. The scope of the ovn-ic is only for the interconnection objects, so I don't see any conflict or ownership ambiguity here. What do you think? > 3. In patch 7,its better to rename the ovs configuration option - > "external_ids:is-interconn" to "external_ids:ovn-is-interconn". >You also need to document it in ovn-controller-8.xml. > Agree! >Or maybe we can remove this option - external_ids:is-interconn. We > probably don't need this if we do like below > >2 (c) can also be done this way > - User creates transit switch. > - ovn-ic creates transit switch in north db. >
Re: [ovs-dev] [PATCH ovn v2 00/13] OVN Interconnection
On Thu, Oct 31, 2019 at 2:43 AM Han Zhou wrote: > > The series supports interconnecting multiple OVN deployments (e.g. located at > multiple data centers) through logical routers connected with tansit logical > switches with overlay tunnels, managed through OVN control plane. See the > ovn-architecture.rst document updates for more details, and find the > instructions in Documentation/tutorials/ovn-interconnection.rst. > > Han Zhou (13): > ovn-architecture: Add documentation for OVN interconnection feature. > ovn-inb: Interconnection northbound DB schema and CLI. > ovn-isb: Interconnection southbound DB schema and CLI. > ovn-ic: Interconnection controller with AZ registeration. > ovn-northd.c: Refactor allocate_tnlid. > ovn-ic: Transit switch controller. > ovn-sb: Add columns is_interconn and is_remote to Chassis. > ovn-ic: Interconnection gateway controller. > ovn-ic: Interconnection port controller. > ovn.at: e2e test for OVN interconnection. > ovn-ctl: Refactor to reduce redundant code. > ovn-ctl: Support commands for interconnection. > tutorial: Add tutorial for OVN Interconnection. > Hi Han, Thanks for working on this feature. It's an interesting use case. I had a quick look at all the patches. I have few comments 1. I would suggest to rename the DBs as ovn-ic-nb.ovsschema (and the same for ovn-isb). The DB name is - OVN_IC_Northbound. So it would make sense to have - ovn-ic-nb.ovsschema I would also suggest to rename the utilities to ovn-ic-nbctl and ovn-ic-sbctl. With ovn-inbctl/ovn-isbctl, it is really confusing. 2. ovn-ic service writes to interconnect south db, ovn north db and ovn south db. Writing to ic south db and ovn north db is fine. But it seems a little odd for ovn-ic to write to south db. From what I understand it writes to south db for 3 purposes a. Updating the tunnel_key column of datapath_binding representing the transit switch b. Updating the key column of port_binding representing the logical router port connecting to the transit switch. c. Creating chassis rows for remote gateway chassis. I think it's better if ovn-ic can delegate all these to ovn-northd. For (a) and (b), ovn-ic can set the generated tunnel key in the other_config/options column of Logical switch/Logical switch port. ovn-northd can internally set this value to the south db. For (c), I think its better we add another table - Remote_Chassis (or some other appropriate name) . ovn-ic will create rows in this table for each remote chassis and ovn-northd will create chassis row in south db. We already have Gateway_Chassis table in North db. So I think it's fine if we add Remote_Chassis table. The only odd thing would be is to store the encap details in North db. With this, ovn-ic, doesn't need to worry about syncing between interconnect south db and ovn south db. In my opinion ovn-ic should act more like CMS to each availability zone and hence should not do any write transactions to the south db. Any concerns with this proposed approach ? 3. In patch 7,its better to rename the ovs configuration option - "external_ids:is-interconn" to "external_ids:ovn-is-interconn". You also need to document it in ovn-controller-8.xml. Or maybe we can remove this option - external_ids:is-interconn. We probably don't need this if we do like below 2 (c) can also be done this way - User creates transit switch. - ovn-ic creates transit switch in north db. - then the user adds the logical router port - logical switch port to the transit switch in availability zone - az1 (for example) - then the user creates gw chassis - for example ovn-nbctl lrp-set-gateway-chassis lrp-lr1-ts1 [priority] - ovn-ic on az1 ,learns this and creates a Gateway_Chassis row in the interconnect south db. - ovn-ic on other az's then create Remote_Chassis rows in the North db. - ovn-northd on other az's then create chassis row in south db with "is_remote" set to true. I am not sure if this complicates further and hence its better that ovn-ic writes to the south dbs. But we can discuss further on this. 4. Can you please add a section in ovn-architecture about the "Journey of a packet in inter-az scenario" ? This would really help in understanding the feature. Thanks Numan > .gitignore |6 + > Documentation/automake.mk |1 + > Documentation/tutorials/index.rst |1 + > Documentation/tutorials/ovn-interconnection.rst | 188 > Makefile.am |1 + > NEWS|5 + > TODO.rst| 10 + > automake.mk | 75 ++ > controller/binding.c|6 +- > controller/chassis.c
