Open Stack

Thanks Ihar, Thierry and Bob. I think we've agreed to go with the 1st option - "Get Neutron to call XenAPI directly rather than trying to use a daemon".
I will refine the POC patch to make it ready for the formal review.

R.g.t the test, I did some basic test in a real lab manually and it worked as expected. For sure more tests will be done forwarding. We will evaluate if to change the XenServer CI to use the daemon mode once this fix got merged.

Regards,
Jianghua

-----Original Message-----
From: Ihar Hrachyshka [mailto:ihrachys at redhat.com] 
Sent: Thursday, November 03, 2016 10:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] proposal to resolve a rootwrap problem for XenServer

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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev