Open Stack

On Wed, 2021-03-03 at 23:50 +1300, Lingxian Kong wrote:
> On Wed, Mar 3, 2021 at 5:15 PM Sean Mooney <smooney at redhat.com> wrote:
> 
> > On Wed, 2021-03-03 at 15:59 +1300, Lingxian Kong wrote:
> > > Hi,
> > > 
> > > Thanks for all your hard work on this.
> > > 
> > > I'm wondering is there any doc proposed for devstack to tell people who
> > are
> > > not interested in OVN to keep the current devstack behaviour? I have a
> > > feeling that using OVN as default Neutron driver would break the CI jobs
> > > for some projects like Octavia, Trove, etc. which rely on ovs port for
> > the
> > > set up.
> > 
> > well ovn is just an alternivie contoler for ovs.
> > so ovn replace the neutron l2 agent it does not replace ovs.
> > project like octavia or trove that deploy loadblances or dbs in vms should
> > not be able to observe a difference.
> > they may still want to deploy ml2/ovs but unless they are doing something
> > directly on the host like adding port
> > directly to ovs because they are not using vms they should not be aware of
> > this change.
> > 
> 
> Yes, they are.
> 
> Please see
> https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L466 as
> an example for Octavia.
right but octavia really should not be doing that.

i mean it will still work in the sense that ovn shoudl be abel to correalte that port to this hos if you have correcly bound that port too
the host but adding internal ports to br-int to provide network connectivy seams like a hack.
ml2/ovn still calls the amin ovs bridge br-int so the port add will work as it did before.

the br-int is owned by neutron and operators are not allowed to add flows or interface to that brdige normally.
so in a real deployment i woudl hope that the woiuld not be adding this port and assigning a mac or ip rules like this.
conenctiviy shoudl be provided via the br-ex /phsyical netowrk using provider networking right?

in anycase you can swap back to ml2/ovs for ocatvia jobs.
if you have correctly bound the manament port to the current host then i think ovn shoudl be able to install the correct
openflow rules to allow it to function however so it may be as simipar as extending the elif to work with ovn.

the port create on https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L458 does seam to have set the host properly
its still kind of troubling to me to see something like this being down our side an openstack agent on the host. for example i would
have expected an ml2 l2 openvswigh agent extntion to create the prot via os-vif or similar in respocne to the api action instead of
manually doing this.

> ---
> Lingxian Kong
> Senior Cloud Engineer (Catalyst Cloud)
> Trove PTL (OpenStack)
> OpenStack Cloud Provider Co-Lead (Kubernetes)