<p dir="ltr">IIRC there was some work to make the plugging call out to a script so all of the calls to various vswitches don't need to be in Nova. I would prefer this to removing all plugging logic from Nova. </p>
<p dir="ltr">The main reason I would be hesitant to leave plugging completely out of Nova is that it requires an agent on the compute node, which isn't the case right now (e.g. plugins based on openflow, ovsdb, or something similar with a remote controller handling the setup of forwarding logic). </p>
<div class="gmail_quote">On Apr 9, 2015 5:27 PM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 4/9/2015 8:56 AM, Neil Jerram wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/04/15 22:07, Michael Still wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
priorities and specs<br>
===============<br>
<br>
I think the current spec process is starting to work well for us, and<br>
that priorities was a success. We should continue with specs, but with<br>
an attempt to analyse why so many approved specs don’t land [...]<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
nova-net<br>
=======<br>
<br>
OMG, this is still a thing. We need to actually work out what we’re<br>
doing here, and then do it. [...]<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
conclusion<br>
========<br>
<br>
I make no claim that my list is exhaustive. What else do you think we<br>
should be tackling in Liberty?<br>
</blockquote>
<br>
Something kind of related to two of the strands above, from the point of<br>
view of someone who had an approved networking-related Nova spec that<br>
failed to land for Kilo...<br>
<br>
Basically, should Nova try harder to get out of the networking business?<br>
Currently the situation is that OpenStack networking experimentation<br>
is mostly in Neutron (as I assume it should be) but also often requires<br>
changes to the VIF type code in Nova. Should we try to close off that<br>
situation, I would guess through some structural solution that puts all<br>
the required code changes firmly into Neutron's domain?<br>
</blockquote>
<br>
Yes, this isn't just Neutron, it's also storage backends with Cinder, see nova.virt.libvirt.volume.<br>
<br>
At one point in this release I tried to wrap my head around why we have all of this VIF plugging gorp inside nova and requires a nova change to enable neutron plugins. This all happened before I was working on the project, but my takeaway was this was how nova got neutron up and running at the time with the way nova was architected for nova-network, but is like fitting a square peg in a round hole, i.e. the virt driver has to do something locally so the neutron agent picks up that change and tells the neutron server and meanwhile nova is waiting on the vif plugging callback event from neutron so it can continue with the server build request (and that's only the libvirt driver). I'm not really sure why nova can't simply call a neutron API to do the plug and then wait for a response that it's done, but leave all of the messy neutron plugin-specific binding stuff in neutron and abstract it away from nova. Same goes for cinder and connecting/disconnecting volumes.<br>
<br>
But I'm naive, so just my 2 cents here.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't want to prejudge what the solution might be. My point here is<br>
to suggest discussing and deciding whether this could be a worthwhile<br>
priority. If it sounds of interest, I could add something to the<br>
etherpad for Nova design session ideas.<br>
<br>
(I appreciate that the nova-net question is way bigger and more<br>
practically important overall than my specific point about the VIF type<br>
code. However it is possible that the VIF type code contributes to a<br>
continuing lack of clarity about where networking function lies in<br>
OpenStack.)<br>
<br>
Regards,<br>
Neil<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>