Open Stack

Le 18/11/2015 16:34, Sean Dague a écrit :
> On 11/17/2015 05:31 PM, Matt Riedemann wrote:
>>
>> 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.
> Yes, I like also using the deprecated_for_removal flags, and I don't
> want to change that.
>
> This is just for the case of "we're going to change the default on the
> next release". I think in that case, a release note is the right thing.
> We don't need new fancy code for that.

I usually hate saying just +1 in an email, but...

+1
> 	-Sean
>
>
>
> __________________________________________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151118/166c9354/attachment.html>