Open Stack

Thierry Carrez <thierry at openstack.org> wrote:

> Bob Ball wrote:
>>>> Oslo.privsep seem try to launch a daemon process and set caps for this
>>> daemon; but for XenAPI, there is no need to spawn the daemon.
>>>
>>> I guess I'm lacking some context... If you don't need special rights,  
>>> why use a
>>> rootwrap-like thing at all ? Why go through a separate process to call  
>>> into
>>> XenAPI ? Why not call in directly from Neutron code ?
>>
>> It does not need to go through a separate process at all, or need  
>> special rights - see the prototype code at  
>> https://review.openstack.org/#/c/390931/ which started this thread,  
>> which is directly calling from Neutron code.
>>
>> I guess the argument is that we are trying to run "configure something"  
>> which in some cases is privileged in the same host as is running the  
>> Neutron code itself, hence the easiest way to do that is to use a  
>> rootwrap.  To me, the very use of a "rootwrap" or "privsep" implies that  
>> we're running the commands in the same host.
>
> OK, I think I get it now: Neutron is using its rootwrap call interface
> as an indirection layer to route configuration commands either to
> execute as root locally (through classic rootwrap) or to execute on dom0
> through a XenAPI connection (through rootwrap-xen-dom0). The latter
> should really have been called xendom0wrap :)
>
>> Arguably we should have a "per logical component" wrapper - in this case  
>> the network / OVS instance that's being managed - as each component  
>> could be in a different location.
>> Mounting a loopback device (which Nova has needed to do in the past)  
>> clearly needs a rootwrap that runs in the same host as Nova, but when  
>> managing the OVS in XenServer's dom0 it needs a similar mechanism to  
>> what we are proposing for Neutron.
>>
>> For reference, Nova has a XenAPI session similar to the above and will  
>> invoke plugins that exist in Dom0 directly, to make the required  
>> modifications.  This is similar in approach to the prototype code above.
>>
>> The current XenAPI rootwrap for Neutron[1] is stupidly inefficient as it  
>> was based on the original rootwrap concept (which neutron replaced with  
>> the daemon mode to improve performance).  As this is a separate  
>> executable, called once for each command, it will create a new session  
>> with each call.  There are (as always) multiple ways to fix this:
>>
>> 1) Get Neutron to call XenAPI directly rather than trying to use a  
>> daemon - the session management would move from  
>> neutron-rootwrap-xen-dom0 into xen_rootwrap_client.py (perhaps this  
>> could be better named)
>
> I personally like that option.

I am puzzled. Is Neutron the only component that need to call to dom0? 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.

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.

Ihar