<br><br><div class="gmail_quote">On Fri, Jan 25, 2013 at 3:00 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">
><br>
> But, for example, the NVP plugin can control KVM, XenServer, and soon ESX<br>
> (waiting on a code change to add some more logic to ESX vif-plugging, which<br>
> is one of the reasons I'm mentioning it as a specific example).  With KVM<br>
> vs. ESX, the data returned is different in kind (i.e., one is a linux<br>
> bridge name, another is a port-group).  And with KVM and XenServer, even<br>
> though they are same same in kind (both bridge names), they are very likely<br>
> to be different in form, since XenServer generates bridge names using a<br>
> standard format (e.g., xapi0, or xenbr1).  Below you propose something that<br>
> with a very minor tweak would solve this concern, I believe.<br>
<br>
</div></div>Ok, so it sounds like we're in agreement then that my plan for the libvirt<br>
VIF drivers can work, as long as we also do the enhancement we describe<br>
below about passing supported vif types.<br></blockquote><div><br></div><div>Yeah.  Only thing I would add is that I think we also need some kind of nova node-id, to handle the case where a different bridge-id is needed even between different nodes that use the same vif_type (mentioned in prev email).  </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Can you point me to the code for the NVP plugin ? Unless I'm missing<br>
something I don't see any plugin called 'nvp' in Quantum GIT ?<br></blockquote><div><br></div><div>sorry, as garyk mentioned, its the nicira plugin: <a href="https://github.com/openstack/quantum/tree/master/quantum/plugins/nicira/nicira_nvp_plugin">https://github.com/openstack/quantum/tree/master/quantum/plugins/nicira/nicira_nvp_plugin</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> This adds some more complexity to Quantum, as the centralized<br>
> quantum-server must know the mapping from a node-id to bridge-id +<br>
> vif_type, but some part of the Quantum plugin must know this information<br>
> already (e.g., an agent), so it would really just be a matter of shifting<br>
> bits around within Quantum, which seems reasonable given time to implement<br>
> this.<br>
<br>
</div>Ok, so the only thing to worry about now is timing. Is it reasonable to<br>
get this enhancement done for Grizzly, so that I can safely deprecate<br>
the VIF plugins in libvirt, or do we need to wait for one more cycle<br>
meaning I should remove the deprecation log messages temporarily ?<br></blockquote><div><br></div><div>Yes, timing/deprecation/backward-compat.  </div><div><br></div><div>The need to be able to handle different bridge-names on different nova-compute nodes  complicates the tasks, even for those plugins that only support a single vif-type (and thus otherwise would have been simple to update).   In some cases, this is exacerbated by the fact that sometimes the plugin and nova use different types of IDs for the same thing (e.g., nova uses XenServer bridge name, plugin uses XenServer Network UUID).  Given that people are already heavily loaded pushing for G-3, which is in about 3 weeks, I think it would be difficult/impossible to mandate this change (especially since it might require changes to third-party systems that are outside the OpenStack code-base).  Besides, his is effectively equivalent to making new API "required" for Quantum, which is something we can't just do at the last minute.  </div>

<div><br></div><div>So taking a step back, I wanted to think about what our goals in terms of deprecation.</div><div><br></div><div>My assumption is that your code refactoring will go through in Grizzly regardless, so this is more about impact on operators, rather than impact on developers (let me know if this isn't your impression).  </div>

<div><br></div><div>The conversation so far in the thread seems to focus on when the old vif-plugging flags would be removed.  I was actually thinking of it from another angle, which lead me to two questions: </div><div>
<br>
</div><div>1) When we do start warning an operator if they are using Nova + Quantum with a plugin that does not support this vif-plugging extension? This should not be before all plugins have had fair time to implement the extension, as no one should have to have their users deal with the warning unless they have been delinquent.  My current thinking based on thoughts about the complexity and the deadline is that this will have to be "H".  </div>

<div><br></div><div>2) What type of warning/error should we give if the operator has configured "old-style" vif-plugging options when using a Quantum plugin that DOES support the vif-plugging extension, and which of the two behaviors would be used (presumably, the behavior dictated by the old-style for backward compat reasons).  </div>

<div><br></div><div>This led me to wonder if we could do the following: if the Quantum plugin in use supports the  vif-plugging extension, ignore the local vif-plugging config and use the "universal driver" with the config from quantum (probably while issuing a warning).  I think it should be feasible in the "H" release to make the vif-plugging extension mandatory for Quantum, at which point, there would always be a warning for any user that specifies an old-style vif-plugging option (assuming H-release was being used for Nova + Quantum).   Starting with H-series we would no longer document the old-style vif-plugging options, and users would get warnings if they were left-over in configs due to an upgrade, but nothing would break, because they weren't required to specify a new type of vif-plugging. </div>

<div><br></div><div>I think this addresses Gary's concern about not breaking any setups on upgrade, which I think we all agree is a good goal, while still enabling a quick transition, but maybe I'm missing something.  Thoughts? </div>

<div><br></div><div>Dan</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<div class="HOEnZb"><div class="h5">Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>