Thierry Carrez <thie...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
