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 :| _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
