[openstack-dev] [all] config options not correctly deprecated
Daniel P. Berrange
berrange at redhat.com
Fri Nov 14 10:06:27 UTC 2014
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, 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 linked to from the Nova upgrade
> >> section in the Juno release notes (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 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
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.
|: 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 :|
More information about the OpenStack-dev