Open Stack

On 10/11/14 11:00, 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 bug has been opened against oslo.config to log these in future so
hopefully this wont be a problem in future releases
https://bugs.launchpad.net/oslo.config/+bug/1390408

> 
>> 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.
Yup and I have no objection to this but the lack of log warning means in
our case nothing flags potential problems with tripleo.

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

tripleo don't generate the sample config anywhere, we should probably in
future check what we are using against it at least once towards the end
of each cycle which should help us spot problems earlier in future.

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

In our case, we are always deploying from trunk so to most practical
place to find places where we are using deprecated codepaths is in the
logs generated, I had been under the assumption this was enough as all
cases would be generated there, in future releases I think it is the
most obvious place to make a deprecation more obvious in all cases.

If I am the only one who had this assumption then fair enough but if
other deployers currently expect that warning logs are generated in all
cases where deprecated code is used then I think this should still be
considered a bug.

> 
>> I've also opened a bug for this against tripleo, nova and oslo.conf[5]
>> and for the moment in tripleo-ci I have pinned the version of nova we
>> use to something from before the commits were merged while we get a
>> chance to correctly use the new name for each of the options that were
>> deprecated.
>>
>> On a side node, When trying to look up the deprecation policy I wasn't
>> able to find it so if anybody has a link handy can you point me at it.
> 
> I'm not aware of it being written down - it is just one of those
> policies that is "herd" knowledge. At the start of each release
> cycle we delete all deprecated bits from the previous release
> cycle, whether they are config options, classes, methods, or any
> other part of nova tree. We've been doing this for as long as I've
> been involved in Nova.

Yup, this is what I thought and I don't really have a problem with this
policy, I was just curious if it was formalised anywhere.

> 
> Regards,
> Daniel
>