<div dir="ltr">FYI, I've forwarded this thread to the operators mailing list as I feel they will be very much interested by this discussion.<br>BR<br>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 1:37 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/13/2014 06:56 PM, Clint Byrum wrote:<br>
> Excerpts from Ben Nemec's message of 2014-11-13 15:20:47 -0800:<br>
>> On 11/10/2014 05:00 AM, Daniel P. Berrange wrote:<br>
>>> On Mon, Nov 10, 2014 at 09:45:02AM +0000, Derek Higgins wrote:<br>
>>>> Tl;dr oslo.config wasn't logging warnings about deprecated config<br>
>>>> options, do we need to support them for another cycle?<br>
>>> AFAIK, there has not been any change in olso.config behaviour<br>
>>> in the Juno release, as compared to previous releases. The<br>
>>> oslo.config behaviour is that the generated sample config file<br>
>>> contain all the deprecation information.<br>
>>><br>
>>> The idea that olso.config issue log warnings is a decent RFE<br>
>>> to make the use of deprecated config settings more visible.<br>
>>> This is an enhancement though, not a bug.<br>
>>><br>
>>>> A set of patches to remove deprecated options in Nova was landed on<br>
>>>> Thursday[1], these were marked as deprecated during the juno dev cycle<br>
>>>> and got removed now that kilo has started.<br>
>>> Yes, this is our standard practice - at the start of each release<br>
>>> cycle, we delete anything that was marked as deprected in the<br>
>>> previous release cycle. ie we give downstream users/apps 1 release<br>
>>> cycle of grace to move to the new option names.<br>
>>><br>
>>>> Most of the deprecated config options are listed as deprecated in the<br>
>>>> documentation for nova.conf changes[2] linked to from the Nova upgrade<br>
>>>> section in the Juno release notes[3] (the deprecated cinder config<br>
>>>> options are not listed here along with the allowed_direct_url_schemes<br>
>>>> glance option).<br>
>>> The sample  nova.conf generated by olso lists all the deprecations.<br>
>>><br>
>>> For example, for cinder options it shows what the old config option<br>
>>> name was.<br>
>>><br>
>>>   [cinder]<br>
>>><br>
>>>   #<br>
>>>   # Options defined in nova.volume.cinder<br>
>>>   #<br>
>>><br>
>>>   # Info to match when looking for cinder in the service<br>
>>>   # catalog. Format is: separated values of the form:<br>
>>>   # <service_type>:<service_name>:<endpoint_type> (string value)<br>
>>>   # Deprecated group/name - [DEFAULT]/cinder_catalog_info<br>
>>>   #catalog_info=volume:cinder:publicURL<br>
>>><br>
>>> Also note the deprecated name will not appear as an option in the<br>
>>> sample config file at all, other than in this deprecation comment.<br>
>>><br>
>>><br>
>>>> My main worry is that there were no warnings about these options being<br>
>>>> deprecated in nova's logs (as a result they were still being used in<br>
>>>> tripleo), once I noticed tripleo's CI jobs were failing and discovered<br>
>>>> the reason I submitted 4 reverts to put back the deprecated options in<br>
>>>> nova[4] as I believe they should now be supported for another cycle<br>
>>>> (along with a fix to oslo.config to log warnings about their use). The 4<br>
>>>> patches have now been blocked as they go "against our deprecation policy".<br>
>>>><br>
>>>> I believe the correct way to handle this is to support these options for<br>
>>>> another cycle so that other operators don't get hit when upgrading to<br>
>>>> kilo. While at that same time fix oslo.config to report the deprecated<br>
>>>> options in kilo.<br>
>>>> I have marked this mail with the [all] tag because there are other<br>
>>>> projects using the same "deprecated_name" (or "deprecated_group")<br>
>>>> parameter when adding config options, I think those projects also now<br>
>>>> need to support their deprecated options for another cycle.<br>
>>> AFAIK, there's nothing different about Juno vs previous release cycles,<br>
>>> so I don't see any reason to do anything different this time around.<br>
>>> No matter what we do there is always a possibility that downstream<br>
>>> apps / users will not notice and/or ignore the deprecation. We should<br>
>>> certainly look at how to make deprecation more obvious, but I don't<br>
>>> think we should change our policy just because an app missed the fact<br>
>>> that these were deprecated.<br>
>> So the difference to me is that this cycle we are aware that we're<br>
>> creating a crappy experience for deployers.  In the past we didn't have<br>
>> anything in the CI environment simulating a real deployment so these<br>
>> sorts of issues went unnoticed.  IMHO telling deployers that they have<br>
>> to troll the sample configs and try to figure out which deprecated opts<br>
>> they're still using is not an acceptable answer.<br>
>><br>
> I don't know if this is really fair, as all of the deprecated options do<br>
> appear here:<br>
><br>
> <a href="http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html" target="_blank">http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html</a><br>
><br>
> So the real bug is that in TripleO we're not paying attention to the<br>
> appropriate stream of deprecations. Logs on running systems is a mighty<br>
> big hammer when the documentation is being updated for us, and we're<br>
> just not paying attention in the right place.<br>
><br>
> BTW, where SHOULD continuous deployers pay attention for this stuff?<br>
><br>
>> Now that we do know, I think we need to address the issue.  The first<br>
>> step is to revert the deprecated removals - they're not hurting<br>
>> anything, and if we wait another cycle we can fix oslo.config and then<br>
>> remove them once deployers have had a reasonable chance to address the<br>
>> deprecation.<br>
>><br>
> In this case, we can just fix the templates. Are we broken? Yes. Can we<br>
> fix it? YES! I would definitely appreciate the reverts preceding that,<br>
> so that we can land other things without having to pin Nova, but we can<br>
> deal if that isn't an option.<br>
><br>
> If we can ask that projects use 'check experimental' whenever they remove<br>
> anything deprecated and take the failures seriously, that will help with<br>
> this. We're trying our best to come up with good policies to keep up,<br>
> but sometimes we fall behind or, in this case, had no good policy for<br>
> keeping up.<br>
><br>
>> This is one of the big reasons we want to have a deployment program<br>
>> upstream.  It surfaces these sorts of shortcomings in a way that<br>
>> probably wouldn't have happened before.  I think it would be a shame if<br>
>> we ignore that because "we've always done it that way."<br>
>><br>
> Thanks Ben, that is indeed why we are still very much interested in<br>
> having TripleO in the integrated gate some day. That said, if we can't<br>
> keep up with the stream of config changes needed, we'll just be a thorn<br>
> in the side of each project that wants to move forward. So we need to<br>
> get better at keeping up with the times.<br>
</div></div>I also think that there was a fall through the cracks with deprecation<br>
functionality moving into oslo. I know when I wrote a lot of that for<br>
Nova we were really verbose about deprecations (some times too much so).<br>
Testing that anything using deprecation functionality in oslo generates<br>
log streams would be really good.<br>
<span class="HOEnZb"><font color="#888888"><br>
    -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>