Bob Ball <bob.b...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
