<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 11, 2014 at 7:41 PM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
</span>Yes, I really think this is a key point. When we introduced the VIF type<br>
mechanism we never intended for there to be soo many different VIF types<br>
created. There is a very small, finite number of possible ways to configure<br>
the libvirt guest XML and it was intended that the VIF types pretty much<br>
mirror that. This would have given us about 8 distinct VIF type maximum.<br>
<br>
I think the reason for the larger than expected number of VIF types, is<br>
that the drivers are being written to require some arbitrary tools to<br>
be invoked in the plug & unplug methods. It would really be better if<br>
those could be accomplished in the Neutron code than the Nova code, via<br>
a host agent run & provided by the Neutron mechanism.  This would let<br>
us have a very small number of VIF types and so avoid the entire problem<br>
that this thread is bringing up.<br>
<br>
Failing that though, I could see a way to accomplish a similar thing<br>
without a Neutron launched agent. If one of the VIF type binding<br>
parameters were the name of a script, we could run that script on<br>
plug & unplug. So we'd have a finite number of VIF types, and each<br>
new Neutron mechanism would merely have to provide a script to invoke<br>
<br>
eg consider the existing midonet & iovisor VIF types as an example.<br>
Both of them use the libvirt "ethernet" config, but have different<br>
things running in their plug methods. If we had a mechanism for<br>
associating a "plug script" with a vif type, we could use a single<br>
VIF type for both.<br>
<br>
eg iovisor port binding info would contain<br>
<br>
  vif_type=ethernet<br>
  vif_plug_script=/usr/bin/neutron-iovisor-vif-plug<br>
<br>
while midonet would contain<br>
<br>
  vif_type=ethernet<br>
  vif_plug_script=/usr/bin/neutron-midonet-vif-plug<br>
<br>
<br>
And so you see implementing a new Neutron mechanism in this way would<br>
not require *any* changes in Nova whatsoever. The work would be entirely<br>
self-contained within the scope of Neutron. It is simply a packaging<br>
task to get the vif script installed on the compute hosts, so that Nova<br>
can execute it.<br>
<br>
This is essentially providing a flexible VIF plugin system for Nova,<br>
without having to have it plug directly into the Nova codebase with<br>
the API & RPC stability constraints that implies.<br>
<span class="im"><br></span></blockquote><div><br></div><div>+1</div><div><br></div><div>Port binding mechanism could vary among different networking technologies, which is not nova's concern, so this proposal makes sense.  Note that some vendors already provide port binding scripts that are currently executed directly from nova's vif.py ('mm-ctl' of midonet and 'ifc_ctl' for iovisor are two such examples), and this proposal makes it unnecessary to have these hard-coded in nova.  The only question I have is, how would nova figure out the arguments for these scripts?  Should nova dictate what they are?</div><div><br></div><div>Ryu</div></div><br></div></div>