Open Stack

On Fri, Jan 25, 2013 at 01:58:32PM +0200, Gary Kotton wrote:
> On 01/25/2013 01:36 PM, Daniel P. Berrange wrote:
> >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.
> 
> The backward compatibility is great and is appreciated.
> 
> >
> >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.
> 
> We can agree to disagree. Folsom Nova/Quantum is used today in
> production. I do not think that we should force a user to make any
> changes to their configuration to ensure that things continue to
> work - in my opinion this is only in extreme circumstances and
> should be very well documented. Digging in log files to find that a
> configuration variable is no longer supported is like looking for a
> needle in a haystack.

Of course all such config changes would also explicitly documented in
release notes, both mentioning the initial deprecation and the final
removal. It is already standard practice to document this. The log
message is just another alert in case the admin ignores the docs.

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