<div dir="ltr">In case it wasn't already assumed, anyone is welcome to contact me directly (irc: gus, email, or in Austin) if they have questions or want help with privsep integration work. It's early days still and the docs aren't extensive (ahem).<div><br></div><div>os-brick privsep change just recently merged (yay), and I have the bulk of the neutron ip_lib conversion almost ready for review, so os-vif is a good candidate to focus on for this cycle.</div><div><br></div><div> - Gus</div><br><div class="gmail_quote"><div dir="ltr">On Thu, 14 Apr 2016 at 01:52 Daniel P. Berrange <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I won't be present at the forthcoming Austin summit, so to prepare other<br>
people in case there are f2f discussions, this is a rough status report<br>
on the os-vif progress<br>
<br>
<br>
os-vif core<br>
-----------<br>
<br>
NB by os-vif core, I mean the python packages in the os_vif/ namespace.<br>
<br>
The object model for describing the various different VIF backend<br>
configurations is defined well enough that it should cover all the<br>
VIF types currently used by Nova libvirt driver, and probably all<br>
those needed by other virt drivers. The only exception is that we<br>
do not have a representation for the vmware 'dvs' VIF type. There's<br>
no real reason why not, other than the fact that we're concentrating<br>
on converting the libvirt nova driver first. These are dealt with<br>
by the os_vif.objects.VIFBase object and its subclasses.<br>
<br>
<br>
We now have an object model for describing client host capabilities.<br>
This is dealt with by the os_vif.objects.HostInfo versioned object<br>
and things is used. Currently this object provides details of all<br>
the os-vif plugins that are installed on the host, and which VIF<br>
configs objects each supports. The intent is that the HostInfo<br>
object is serialized to JSON, and passed to Neutron by Nova when<br>
creating a port. This allows Neutron to dynamically decide which<br>
plugin and which VIF config it wants to use for creating the port.<br>
<br>
<br>
The os_vif.PluginBase class which all plugins must inherit from<br>
has been enhanced so that plugins can declare configuration<br>
parameters they wish to support. This allows config options for<br>
the plugins to be included directly in the nova.conf file in<br>
a dedicated section per plugin. For example, the linux bridge<br>
plugin will have its parameters in a "[os_vif_linux_bridge]"<br>
section in nova.conf. This lets us setup the deprecations<br>
correctly, so that when upgrading from older Nova, existing<br>
settings in nova.conf still apply to the plugins provided<br>
by os-vif.<br>
<br>
<br>
os-vif reference plugins<br>
------------------------<br>
<br>
Originally the intention was that all plugins would live outside<br>
of the os-vif package. During discussions at the Nova mid-cycle<br>
meeting there was a strong preference to have the linux bridge<br>
and openvswitch plugin implementations be distributed as part of<br>
the os-vif package directly.<br>
<br>
As such we now have 'vif_plug_linux_bridge' and 'vif_plug_ovs'<br>
python packages as part of the os-vif module. Note that these<br>
are *not* under the os_vif python namespace, as the intention<br>
was to keep their code structured as if they were separate,<br>
so we can easily split them out again in future in we need to.<br>
<br>
Both the linux bridge and ovs plugins have now been converted<br>
over to use oslo.privsep instead of rootwrap for all the places<br>
where they need to run privileged commands.<br>
<br>
<br>
os-vif extra plugins<br>
--------------------<br>
<br>
Jay has had GIT repositories created to hold the plugins for all<br>
the other VIF types the libvirt driver needs to support to have<br>
feature parity with Mitaka and earlier. AFAIK, no one has done<br>
any work to actually get the code for these working. This is not<br>
a blocker, since the way the Nova integration is written allows<br>
us to incrementally convert each VIF type over to use os-vif, so<br>
we avoid need for a "big bang".<br>
<br>
<br>
os-vif Nova integration<br>
-----------------------<br>
<br>
I have a patch up for review against Nova that converts the libvirt<br>
driver to use os-vif. It only does the conversion for linux bridge<br>
and openvswitch, all other vif types fallback to using the current<br>
code, as mentioned above. The unit tests for this pass locally,<br>
but I've not been able to verify its working correctly when run for<br>
real. There's almost certainly privsep related integration tasks to<br>
shake out - possibly as little as just installing the rootwrap filter<br>
needed to allow use of privsep. My focus right now is ironing this<br>
out so that I can verify linux bridge + ovs work with os-vif.<br>
<br>
<br>
There is a new job defined in the experimental queue that tests that<br>
can verify Nova against os-vif git master so we can get forwarning<br>
if something in os-vif will cause Nova to break. This should also<br>
let us verify that the integration is actually working in Nova CI<br>
before allowing it to actually merge.<br>
<br>
<br>
os-vif Neutron integration<br>
--------------------------<br>
<br>
As mentioned earlier we now have a HostInfo versioned object defined<br>
in os-vif which Nova will populate. We need to extend the Neutron API<br>
to accept this object when nova creates a port. This lets Neutron know<br>
which VIF plugins are available and the configs they require.<br>
<br>
Once Neutron has this information, instead of sending back the current<br>
unstructured port binding dict, it will be able to send back a serialized<br>
os_vif.objects.VIFBase subclass which formally describes the VIF it wants<br>
Nova to use. This might be possible by just defining a VIF_TYPE_OS_VIF<br>
and putting the VIFBase serialized data in another port binding metadata<br>
field. Alternatively it might be desirable to extend the Neutron API to<br>
more explictly represent os-vif.<br>
<br>
None of the Neutron integration has been started, or even written up<br>
since it is not a blocker for completing the Nova conversion. None the<br>
less there is a strong desire from Neutron side to be able to dynamically<br>
choose between different VIF types, so the sooner we start this the better.<br>
<br>
<br>
Neuton work items<br>
-----------------<br>
<br>
Based on that the work items that we have for Neuton include<br>
<br>
- Get the initial port of Nova libvirt to use os-vif for linux bridge<br>
and openvswitch. The code is essentially written, just needs debugging<br>
and some magic to ensure it all runs correctly in the gate. This is<br>
my immediate personal task to complete<br>
<br>
- Convert more VIF types in nova libvirt to use os-vif with privsep.<br>
The GIT repos exist, and os-vif core team is setup as the core approvers<br>
for each repo. The intention, however, is that vendors would take<br>
responsiblity for each dealing with creating a os-vif plugin for<br>
their respective VIF types. os-vif core team will provide whatever<br>
assistance is needed to smooth the process. While this is not a firm<br>
blocker, it is desirable if we can get all nova libvirt VIF types<br>
converted to os-vif for Neuton release.<br>
<br>
- Convert other Nova virt drivers to use os-vif. No work has been<br>
started on this. Again, expectation is that respective virt driver<br>
teams would want to lead this effort themselves. We're not going to<br>
force a big-bang conversion to os-vif for other virt drivers during<br>
Neuton. We might want to consider mandating conversion to os-vif<br>
for Ocata though, since the longer we delay the conversion, the<br>
longer it'll be before we can deprecate & drop the old vif support<br>
code.<br>
<br>
- Convert Neutron to use os-vif for communication with Nova. The first<br>
step here is for someone on os-vif core team to write a spec and<br>
post it to neutron-specs, and get the Neutron devs engaged in the<br>
discussion. There will need to be a nova-spec too, but that's really<br>
just about Nova adopting whatever Neutron API changes are decided<br>
upon, so could be just a spec-less blueprint that points to the<br>
neutron spec for the details. No one has started on this, but I was<br>
intending todo so after the initial Nova/os-vif integration was<br>
working.<br>
<br>
<br>
So the only real immediate blocker is getting the initial Nova/libvirt<br>
os-vif integration functional for linux bridge + ovs, to prove that the<br>
overall system is actually working as intended. Once that's merged<br>
everything else can carry on with high degree of parallelization.<br>
<br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
--<br>
Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.<a href="http://www.mailguard.com.au/mg" rel="noreferrer" target="_blank">http://www.mailguard.com.au/mg</a><br>
Click here to report this message as spam:<br>
<a href="https://console.mailguard.com.au/ras/1OedLhIpp0/62ql1cP6GOXhP3dYq6fJM/0.62" rel="noreferrer" target="_blank">https://console.mailguard.com.au/ras/1OedLhIpp0/62ql1cP6GOXhP3dYq6fJM/0.62</a><br>
<br>
</blockquote></div></div>