Open Stack

On 03/03/21 14:29 -0500, Brian Haley wrote:
>On 3/3/21 5:50 AM, Lingxian Kong wrote:
>>On Wed, Mar 3, 2021 at 5:15 PM Sean Mooney <smooney at redhat.com 
>><mailto: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.
>
>The code to do this configuration was all migrated to the neutron 
>repository, with the last bit of cleanup for the Octavia code you 
>highlighted here:
>
>https://review.opendev.org/c/openstack/octavia/+/718192
>
>It just needs a final push to get it merged.
>
>-Brian
>

There's similar plug-into-ovs code used by Manila container and 
generic backend drivers [1], [2], in the manila codebase, not migrated 
into neutron as done for octavia.

Putting my downstream hat on, I'll remark that we tested Manila with 
OVN and run it that way now in production but downstream these drivers 
are not supported so I don't think we know they will work in upstream 
CI.
Incidentally, I have always thought and said that it seems to me to be 
a layer violation for Manila to manipulate the ovs switches directly.  
We should be calling a neutron API.  This would also free us of the 
topology restriction of having to run the Manila share service on the 
node with the OVS switch in question.

[1] https://github.com/openstack/manila/blob/master/manila/share/drivers/container/driver.py#L245
[2] https://github.com/openstack/manila/blob/master/manila/network/linux/ovs_lib.py#L51

-- Tom