Open Stack

> > 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.

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) 
2) Get Neutron to call a local rootwrap daemon (as per the current implementation) which maintains a pool of connections and can efficiently call through to XenAPI
3) Extend oslo.rootwrap (and I presume also privsep) to know that some commands can run in different places, and put the logic for connecting to those different places in there.

We did have a prototype implementation of #2 but it was messy, and #1 seemed architecturally cleaner.

Bob 

[1] http://git.openstack.org/cgit/openstack/neutron/tree/bin/neutron-rootwrap-xen-dom0