Open Stack

On 11/17/2015 2:05 PM, Sylvain Bauza wrote:
>
>
> Le 17/11/2015 20:25, Sean Dague a écrit :
>> On 11/17/2015 01:48 PM, Matt Riedemann wrote:
>>>
>>> On 11/17/2015 11:28 AM, Alexis Lee wrote:
>>>> Often in Nova we introduce an option defaulted off (so as not to break
>>>> people) but then we want to make it default in the next release.
>>>>
>>>> Someone suggested an opt flag to mark this but I don't know what impact
>>>> they wanted it to have. IE how the user should be alerted about the
>>>> presence of these flagged options.
>>>>
>>>> If you are that person, or have opinions on this, please reply :)
>>>>
>>>>
>>>> Alexis (lxsli)
>>>>
>>> There is the deprecated_for_removal kwarg, but that doesn't fit here.
>>> There is the DeprecatedOpt, but that's for moving/renaming options. So
>>> this is something else, like deprecated_default or
>>> pending_default_change or something.
>> Honestly, with reno now we could probably just add a release note in
>> when we add it. That's more likely for us to not loose a thing like that.
>>
>>     -Sean
>>
>
> Agreed, it's now far easier to ask for having a release note within the
> change, so the operators can just look at that. It also seems to me far
> better for them to check the release notes rather than trying to see the
> huge nova.conf file...
>
> -Sylvain
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Sure, a release note is justified, just like when we deprecate or rename 
an option.

The thing I like about the deprecated_for_removal kwarg is the warning 
that gets logged when you are still using the thing. I'm sure people see 
release notes for deprecated things and say, I'll add a TODO to clean 
this up in our tooling, but then get busy and forget about it until they 
break. The annoying warning is a constant indicator that this is 
something you need to move off of sooner rather than later.

Just my 2 cents.

-- 

Thanks,

Matt Riedemann