Open Stack

Bob Ball <bob.ball at citrix.com> wrote:

> Hi Ihar,
>
>> I am puzzled. Is Neutron the only component that need to call to dom0?
>
> No it's not.  Nova has similar code to call plugins in dom0[1], and  
> Ceilometer will also need to make the calls for some metrics not exposed  
> through the formal API.
>
> We don't want code duplication, and are working on a common os-xenapi  
> library which will include session management.
> It would, of course, make sense for Neutron to use this common library  
> when it is available to replace the session management already  
> existing[2], but I'd argue that as there is existing XenAPI session  
> management code, the refactor to avoid using a per-command rootwrap  
> should be independent of using the session code from os-xenapi.

Seems like you are in a position that requires you to hook into neutron  
processes somehow, and it’s either neutron itself (your solution), or a  
library used by neutron (oslo.rootwrap or similar). I understand why you  
picked the first option.

>
>> I would think that Neutron is not in business of handling hypervisor  
>> privilege isolation mechanics, and that
>> some other components will handle that for Neutron (and other services  
>> that may need it), that’s why I
>> suggested to consider oslo.* realm for the proposed code.
>
> This is less about hypervisor privilege isolation and more about the  
> location of the logical component being updated.  Neutron is assuming  
> that the OVS being updated is running in the same location as Neutron  
> itself.  For XenAPI that is not true; the OVS is running in the  
> hypervisor, whereas Neutron is running in a VM (or potentially elsewhere  
> entirely).
>
> If oslo.* is going to decide whether to run a command using a specific  
> abstraction or locally, then it would need some way of making that  
> decision - perhaps either command-based (very ugly and fragile) or with  
> the caller telling oslo.* what logical component was being affected by  
> the call.  The latter sounds to me much more as a Neutron-specific  
> decision.

I believe os-xenapi is a nice path forward. I understand it will take some  
time to shape.

As for the dom0/domU routing decision, yes, it’s indeed on Neutron to make  
it. But it does not mean that we could not rely on existing filtering  
mechanisms (oslo.rootwrap ‘.filters’ files) to define that decision. The  
fact that current netwrap script for Xen duplicates filters from rootwrap  
is unfortunate. It should be a single source of truth.

It would probably require some extensive work in the library, and  
considering that oslo folks moved the library into maintenance mode, it  
probably won’t happen. As for oslo.privsep, that would be a better place  
for such a feature, but we won’t get there in Ocata. Bummer…

I guess I will unblock the patch, and we’ll see what others think. I left  
some initial review comments.

>
>> Side note: if we are going to make drastic changes to existing Xen-wrap  
>> script, we should first have Xen
>> third-party CI testing running against it, not to introduce regressions.  
>> AFAIK it’s not happening right now.
>
> It already is running, and has been for several months - see "Citrix  
> XenServer CI"s "dsvm-tempest-neutron-network" job on  
> https://review.openstack.org/#/c/391308/ as an example.  The CI is  
> non-voting but if it were added to the neutron-ci group we would be very  
> happy to make it voting.

Oh right. It does not validate the new change though. Would be nice to see  
the new ‘daemon’-ic mode behaves in real world.

Ihar