Open Stack

On Fri, Jan 25, 2013 at 01:28:35PM +0200, Gary Kotton wrote:
> On 01/25/2013 01:08 PM, Daniel P. Berrange wrote:
> >On Fri, Jan 25, 2013 at 01:03:33PM +0200, Gary Kotton wrote:
> >>On 01/25/2013 01:00 PM, Daniel P. Berrange wrote:
> >>>On Thu, Jan 24, 2013 at 10:58:43AM -0800, Dan Wendlandt wrote:
> >>>>>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 ?
> >>I am in favour of removing the deprecation log messages.
> >On what basis ? Whether the deprecation messages are appropriate or
> >not depends on whether we can do the enhancements described above
> >for Grizzly or not. Are you saying we can't do those enhancements
> >for Grizzly ?
> 
> First and foremost I do not think that you should force a user to
> change their configuration when upgrading. This defeats the purpose
> in my opinion. I have stated that from the start of this
> development. Not sure if others agree here.

This is *not* forcing the user to change this configuration when
upgrading to Grizzly. I explicitly kept backwards compatibility
with Folsom, so that they can upgrade without changes. What we're
doing is giving them prior warning that they will need to make a
change at some point when they deploy the following Hxxxxx release.

Historically Nova releases have just unconditionally removed
existing config parameters requiring an immediate, unanounnced
change by people deploying. I agree that this is a bad approach.

We can't commit to supporting every single config parameter for
all time though. We need to be able to remove things that no longer
make sense to remain. Having a deprecation warning for one release
cycle prior to the change is the right balance IMHO.

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