Open Stack

On Sun, Jan 27, 2013 at 07:42:42PM -0800, Dan Wendlandt wrote:
> 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).

Yes, that's correct.

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

I was hoping we'd get Quantum fully converted for Grizzly, but given
our discussions it seems we have more work todo than first anticipated.
So I think Hxxxx is a reasonable target. I'll remove the deprecation
warnings from the code for now & re-add them at the start of the Hxxxx
cycle.

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

Yep, if they have configured an old-style VIF driver, it should operate
as in previous releases.

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

Ah, you seem to be thinking that the 'libvirt_vif_driver' config parameter
will go away completely. This is not my intention. I just want to have a
situation where admins do not need to use it for any configuration using
in-tree OpenStack components.

If someone develops a new Quantum plugin out of tree, and needs to also
do some work on the Nova side to support that, we still need to have the
'libvirt_vif_driver' parameter around.

So I don't want to have anything where we magically ignore the
'libvirt_vif_driver' parameter in some scenarios - we should always
honour that parameter. Just that with it configured to LibvirtGenericVIFDriver,
99% of users will never need to touch it now.

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