Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/13/2014 06:37 PM, Sean Dague wrote:
> On 11/13/2014 06:56 PM, Clint Byrum wrote:
>> Excerpts from Ben Nemec's message of 2014-11-13 15:20:47 -0800:
>>> 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.
>>> 
>> I don't know if this is really fair, as all of the deprecated
>> options do appear here:
>> 
>> http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html
>>
>>
>> 
So the real bug is that in TripleO we're not paying attention to the
>> appropriate stream of deprecations. Logs on running systems is a
>> mighty big hammer when the documentation is being updated for us,
>> and we're just not paying attention in the right place.
>> 
>> BTW, where SHOULD continuous deployers pay attention for this
>> stuff?
>> 
>>> 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.
>>> 
>> In this case, we can just fix the templates. Are we broken? Yes.
>> Can we fix it? YES! I would definitely appreciate the reverts
>> preceding that, so that we can land other things without having
>> to pin Nova, but we can deal if that isn't an option.
>> 
>> If we can ask that projects use 'check experimental' whenever
>> they remove anything deprecated and take the failures seriously,
>> that will help with this. We're trying our best to come up with
>> good policies to keep up, but sometimes we fall behind or, in
>> this case, had no good policy for keeping up.
>> 
>>> This is one of the big reasons we want to have a deployment
>>> program upstream.  It surfaces these sorts of shortcomings in a
>>> way that probably wouldn't have happened before.  I think it
>>> would be a shame if we ignore that because "we've always done
>>> it that way."
>>> 
>> Thanks Ben, that is indeed why we are still very much interested
>> in having TripleO in the integrated gate some day. That said, if
>> we can't keep up with the stream of config changes needed, we'll
>> just be a thorn in the side of each project that wants to move
>> forward. So we need to get better at keeping up with the times.
> I also think that there was a fall through the cracks with
> deprecation functionality moving into oslo. I know when I wrote a
> lot of that for Nova we were really verbose about deprecations
> (some times too much so). Testing that anything using deprecation
> functionality in oslo generates log streams would be really good.

AFAIK, all of the deprecation functionality we have is still working
as intended, it's just that we never had anything in oslo.config to
log deprecated opts.  I suspect that's at least in part because
historically we haven't bothered to remove deprecated config opts (I'm
sure it's happened before, but this is the first time I've actually
seen deprecated config opts removed) - they don't hurt anything and
leaving them as a compatibility shim is not a big deal, so that's what
I've always seen done.

For those playing along at home, I think Sean is referring to
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/versionutils.py#L33
and
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/log.py#L274
in Oslo.

- -Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUZjSEAAoJEDehGd0Fy7uqlG8H/2xqsLy8U7QPvnJF3jNC6hbD
mZSRZTheui0a74lWfg9pocUv/GURbT4qDHWHU5FO/l0K2gyEjZt6Nuck0Nme5SLX
9ynwYon392dAWAcB/cP5gX7Qra55FFcWx+MCkwE2zQA9XpVSv5sUMU/TOu0NDFLT
DQGQaA0IvpIAXLB+/YWdMaytzc3kMMhf2p3/gGVvC0/NvoML3FiTID9+M625+UOu
yDKrXHflupTXhxdq55SlXiuA5wdqMIfwkkEePUErIdo1ogI0i5zQgLqYpA4s1uZG
oOf3kiSJOLmKiOSzytPX/wzT/e/bcUPoHYqQo7I3eY8FRMUmDxsqp8k1AtFwilQ=
=5Eab
-----END PGP SIGNATURE-----