Open Stack

On Thu, Nov 13, 2014 at 05:20:47PM -0600, Ben Nemec wrote:
> On 11/10/2014 05:00 AM, Daniel P. Berrange wrote:
> > On Mon, Nov 10, 2014 at 09:45:02AM +0000, Derek Higgins wrote:
> >> Tl;dr oslo.config wasn't logging warnings about deprecated config
> >> options, do we need to support them for another cycle?
> > 
> > AFAIK, there has not been any change in olso.config behaviour
> > in the Juno release, as compared to previous releases. The
> > oslo.config behaviour is that the generated sample config file
> > contain all the deprecation information.
> > 
> > The idea that olso.config issue log warnings is a decent RFE
> > to make the use of deprecated config settings more visible.
> > This is an enhancement though, not a bug.
> > 
> >> A set of patches to remove deprecated options in Nova was landed on
> >> Thursday[1], these were marked as deprecated during the juno dev cycle
> >> and got removed now that kilo has started.
> > 
> > Yes, this is our standard practice - at the start of each release
> > cycle, we delete anything that was marked as deprected in the
> > previous release cycle. ie we give downstream users/apps 1 release
> > cycle of grace to move to the new option names.
> > 
> >> Most of the deprecated config options are listed as deprecated in the
> >> documentation for nova.conf changes[2] linked to from the Nova upgrade
> >> section in the Juno release notes[3] (the deprecated cinder config
> >> options are not listed here along with the allowed_direct_url_schemes
> >> glance option).
> > 
> > The sample  nova.conf generated by olso lists all the deprecations.
> > 
> > For example, for cinder options it shows what the old config option
> > name was.
> > 
> >   [cinder]
> > 
> >   #
> >   # Options defined in nova.volume.cinder
> >   #
> > 
> >   # Info to match when looking for cinder in the service
> >   # catalog. Format is: separated values of the form:
> >   # <service_type>:<service_name>:<endpoint_type> (string value)
> >   # Deprecated group/name - [DEFAULT]/cinder_catalog_info
> >   #catalog_info=volume:cinder:publicURL
> > 
> > Also note the deprecated name will not appear as an option in the
> > sample config file at all, other than in this deprecation comment.
> > 
> > 
> >> My main worry is that there were no warnings about these options being
> >> deprecated in nova's logs (as a result they were still being used in
> >> tripleo), once I noticed tripleo's CI jobs were failing and discovered
> >> the reason I submitted 4 reverts to put back the deprecated options in
> >> nova[4] as I believe they should now be supported for another cycle
> >> (along with a fix to oslo.config to log warnings about their use). The 4
> >> patches have now been blocked as they go "against our deprecation policy".
> >>
> >> I believe the correct way to handle this is to support these options for
> >> another cycle so that other operators don't get hit when upgrading to
> >> kilo. While at that same time fix oslo.config to report the deprecated
> >> options in kilo.
> > 
> >> I have marked this mail with the [all] tag because there are other
> >> projects using the same "deprecated_name" (or "deprecated_group")
> >> parameter when adding config options, I think those projects also now
> >> need to support their deprecated options for another cycle.
> > 
> > AFAIK, there's nothing different about Juno vs previous release cycles,
> > so I don't see any reason to do anything different this time around.
> > No matter what we do there is always a possibility that downstream
> > apps / users will not notice and/or ignore the deprecation. We should
> > certainly look at how to make deprecation more obvious, but I don't
> > think we should change our policy just because an app missed the fact
> > that these were deprecated.
> 
> So the difference to me is that this cycle we are aware that we're
> creating a crappy experience for deployers.  In the past we didn't have
> anything in the CI environment simulating a real deployment so these
> sorts of issues went unnoticed.  IMHO telling deployers that they have
> to troll the sample configs and try to figure out which deprecated opts
> they're still using is not an acceptable answer.
> 
> Now that we do know, I think we need to address the issue.  The first
> step is to revert the deprecated removals - they're not hurting
> anything, and if we wait another cycle we can fix oslo.config and then
> remove them once deployers have had a reasonable chance to address the
> deprecation.

I don't see any compelling reason to revert the deletions. They are
not going to impact most users until Kilo is released, so most operators
have 6 months to advance warning to prepare for this. We just need to
make sure they are more aware of the fact that these will be removed.


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