Open Stack

On Thu, Jan 24, 2013 at 10:58:43AM -0800, Dan Wendlandt wrote:
> > > I completely agree that some fields make sense to multiple
> > hypervisors... I
> > > certainly did not intend to say anything to the contrary.  The point I
> > was
> > > making was that there is no single set of information is relevant to all
> > > hypervisors.  Do you agree with that statement, or are you advocating
> > that
> > > there is a single set of such information?
> > >
> > > Also, I'm still trying to get confirmation to my question above, namely
> > > that you do intend that Quantum would provide all such data needed to
> > plug
> > > a VIF, for example, providing a bridge name to a hypervisor running KVM,
> > or
> > > a port-group id for a hypervisor running ESX.
> >
> > In essence yes. It is hard for me to answer your question about bridge
> > name vs port-group id for ESX because AFAICK there's no plugin that
> > exists for ESX + Quantum today - nova.virt.vmwareapi.vif certainly
> > doesn't appear to have any such code. I'm not overly concerned though.
> >
> 
> I agree that if you look at the simple linux bridge or OVS plugins, they
> follow a very basic model where a vif_type and even bridge name would be
> uniform for an all KVM deployment.
> 
> But, for example, the NVP plugin can control KVM, XenServer, and soon ESX
> (waiting on a code change to add some more logic to ESX vif-plugging, which
> is one of the reasons I'm mentioning it as a specific example).  With KVM
> vs. ESX, the data returned is different in kind (i.e., one is a linux
> bridge name, another is a port-group).  And with KVM and XenServer, even
> though they are same same in kind (both bridge names), they are very likely
> to be different in form, since XenServer generates bridge names using a
> standard format (e.g., xapi0, or xenbr1).  Below you propose something that
> with a very minor tweak would solve this concern, I believe.

Ok, so it sounds like we're in agreement then that my plan for the libvirt
VIF drivers can work, as long as we also do the enhancement we describe
below about passing supported vif types.

Can you point me to the code for the NVP plugin ? Unless I'm missing
something I don't see any plugin called 'nvp' in Quantum GIT ?

> > Maybe we should just make Nova pass across its list of supported
> > vif types during 'create port' regardless of whether we need it
> > now and be done with it.
> >
> 
> Yes, this is what I was thinking as well.  Somewhat of a "negotiation"
> where Nova sends a certain amount of information over (e.g., its supported
> vif_types, its node-id) and then Quantum can determine what vif_type to
> respond with.  I'm thinking that node-id may be needed to handle the case
> where Quantum needs to respond with different data even for the same
> vif_type (e.g., two different esx clusters that have different
> port-group-ids).
> 
> This adds some more complexity to Quantum, as the centralized
> quantum-server must know the mapping from a node-id to bridge-id +
> vif_type, but some part of the Quantum plugin must know this information
> already (e.g., an agent), so it would really just be a matter of shifting
> bits around within Quantum, which seems reasonable given time to implement
> this.

Ok, so the only thing to worry about now is timing. Is it reasonable to
get this enhancement done for Grizzly, so that I can safely deprecate
the VIF plugins in libvirt, or do we need to wait for one more cycle
meaning I should remove the deprecation log messages temporarily ?

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|