On Tue, Jun 20, 2017 at 6:09 AM, Miguel Angel Ajo Pelayo <majop...@redhat.com> wrote: > I'm working on the implementation changes related to the schema [1] > > And I thought it could be great if we discussed here over the cmdline > changes, so this effort could happen in parallel: > > ovn-nbctl lrp-add-gw-chassis <port-name> <chassis-name> [priority] > ovn-nbctl lrp-set-gw-chassis-prio <port-name> <chassis-name> priority > ovn-nbctl lrp-del-gw-chassis <port-name> <chassis-name> > ovn-nbctl lrp-list-gw-chassis <port-name> > > > how does that look ^ ?
Looks OK to me. If you want to save some time, you could just use the generic DB commands for this for now, and come back to it later as a bonus. > > > > [1] https://etherpad.openstack.org/p/ovn-l3ha-schema > > On Wed, Jun 14, 2017 at 10:04 PM, Miguel Angel Ajo Pelayo > <majop...@redhat.com> wrote: >> >> As discussed on IRC let's meet tomorrow at 9am EST to talk about the topic >> on IRC. >> >> >> >> >> El 14 jun. 2017 9:02 p. m., "Russell Bryant" <russ...@ovn.org> escribió: >> >> On Wed, Jun 14, 2017 at 2:40 PM, Miguel Angel Ajo Pelayo >> <majop...@redhat.com> wrote: >> > Hi, sorry, I didn't see your comments this morning. Thanks a lot for all >> > the >> > feedback, I'll shuffle things around. >> > >> > I thought about something like adding new columns too, but I didn't >> > manage >> > to come up with anything that didn't make it less intuitive. >> > >> > The disadvantage of the current format is that you can't filter the >> > monitoring for chassis redirect ports on an specific chassis name (with >> > Current ovsdb API). May be two columns (one for names, another for >> > priorities would let us do that) >> > >> > I'm glad to hear suggestions for column names or structure here :) >> >> I'm happy to collaborate on the proposed alternate schema. Maybe we >> can connect on IRC tomorrow to work on it? >> >> > >> > >> > >> > El 13 jun. 2017 10:41 p. m., "Russell Bryant" <russ...@ovn.org> >> > escribió: >> > >> > On Tue, Jun 13, 2017 at 4:40 PM, Russell Bryant <russ...@ovn.org> wrote: >> >> On Fri, Jun 2, 2017 at 8:31 AM, <majop...@redhat.com> wrote: >> >>> From: Miguel Angel Ajo <majop...@redhat.com> >> >>> >> >>> This patch handles multiple gateways with priorities in >> >>> chassisredirect >> >>> ports, any gateway with a chassis redirect port will implement the >> >>> rules to de-encapsulate incomming packets for such port. >> >>> >> >>> And hosts targetting a remote chassisredirect port will setup a >> >>> bundle(active_backup, ..) action to each tunnel port, in the given >> >>> priority order. >> >>> >> >>> Signed-off-by: Miguel Angel Ajo <majop...@redhat.com> >> >>> --- >> >>> ovn/controller/binding.c | 9 +-- >> >>> ovn/controller/lflow.c | 6 +- >> >>> ovn/controller/lport.c | 119 >> >>> ++++++++++++++++++++++++++++++++++++++++ >> >>> ovn/controller/lport.h | 28 ++++++++++ >> >>> ovn/controller/ovn-controller.c | 5 +- >> >>> ovn/controller/physical.c | 114 >> >>> ++++++++++++++++++++++++++++++++------ >> >>> 6 files changed, 255 insertions(+), 26 deletions(-) >> >> >> >> Some high level comments to start ... >> >> >> >> Ideally with a patch series, each patch should be applicable on its >> >> own. With this patch applied, some tests are failing for me. >> >> >> >> Documentation should also be included with whatever patch first >> >> introduces functionality, so I'd expect docs on the updated >> >> redirect-chassis format here. >> >> >> >> Please read over >> >> Documentation/internals/contributing/coding-style.rst. There are some >> >> minor style issues throughout the patch. I can point them out in a >> >> more detailed pass. >> >> >> >> The patch makes me wonder if we should introduce a more structured >> >> format for specifying chassis associated with a router port. It feels >> >> like we're encoding too much in a single option string. Maybe we >> >> should add a new "chassis" column to Logical_Router_Port, that can >> >> include a list of chassis, which would have to be a new record type in >> >> OVN northbound, containing much less info than the southbound >> >> counterpart. We'd have to add a similar new column to the >> >> Port_Binding table in OVN southbound. I'm curious what you and others >> >> think about this, or if the parsed option string is fine. >> > >> > Sorry, I replied to v1, but all comments apply to v2. >> > >> > -- >> > Russell Bryant >> > >> > >> >> >> >> -- >> Russell Bryant >> >> > -- Russell Bryant _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
