Open Stack

On Fri, Jan 25, 2013 at 3:00 AM, Daniel P. Berrange <berrange at redhat.com>wrote:
>
>  >
> > 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.
>

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).


>
> 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 ?
>

sorry, as garyk mentioned, its the nicira plugin:
https://github.com/openstack/quantum/tree/master/quantum/plugins/nicira/nicira_nvp_plugin


> >
> > 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 ?
>

Yes, timing/deprecation/backward-compat.

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.

So taking a step back, I wanted to think about what our goals in terms of
deprecation.

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).

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:

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".

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).

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.

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?

Dan






>
> 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:|
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130127/7e6e9821/attachment.html>