Open Stack

On Tue, May 17, 2016, at 03:00 PM, Dolph Mathews wrote:
> I think the metadata_manager is one of many terrible examples of
> deprecated configuration options. The documentation surrounding a
> deprecation should *always* tell you why something is being
> deprecated, and what you should be using instead to achieve the
> same, or better, result moving forward. But instead, we get "you
> don't need to see any documentation... these aren't the configs
> you're looking for."
 
In this case there is no replacement to point towards, Nova is just
removing a plug point. But it is fair to say that the reasoning behind
the removal should be captured in the comment there.
 
>
> If all our deprecated config options provided useful pointers in their
> descriptions, there would be tremendous value in retaining deprecated
> configuration options in sample config files -- in which case, I don't
> believe we would be having this conversation which questions their
> value in the first place.
 
If config sample files are being used as a living document then that
would be a reason to leave the deprecated options in there. In my
experience as a cloud deployer I never once used them in that manner so
it didn't occur to me that people might, hence my question to the list.
 
This may also indicate that people aren't checking release notes as we
hope they are. A release note is where I would expect to find this
information aggregated with all the other changes I should be aware of.
That seems easier to me than aggregating that data myself by checking
various sources.
 
Anyways, I have no strong cause for removing the deprecated options. I
just wondered if it was a low hanging fruit and thought I would ask.
 
 
 
>
> On Tue, May 17, 2016 at 1:49 PM Andrew Laski
> <andrew at lascii.com> wrote:
>>
>>
>>
>> On Tue, May 17, 2016, at 02:36 PM, Matt Fischer wrote:
>>> On Tue, May 17, 2016 at 12:25 PM, Andrew Laski <andrew at lascii.com>
>>> wrote:
>>>> I was in a discussion earlier about discouraging deployers from
>>>> using
>>>> deprecated options and the question came up about why we put
>>>> deprecated
>>>> options into the sample files generated in the various projects.
>>>> So, why
>>>> do we do that?
>>>>
>>>> I view the sample file as a reference to be used when setting up a
>>>> service for the first time, or when looking to configure
>>>> something for
>>>> the first time. In neither of those cases do I see a benefit to
>>>> advertising options that are marked deprecated.
>>>>
>>>> Is there some other case I'm not considering here? And how does
>>>> everyone
>>>> feel about modifying the sample file generation to exclude options
>>>> which
>>>> are marked with "deprecated_for_removal"?
>>>>
>>>
>>>
>>> Can you clarify what you mean by having them? The way they are now
>>> is great for deployers I think and people (like me) who work on
>>> things like puppet and need to update options sometimes. For
>>> example, I like this way, example from keystone:
>>>
>>> # Deprecated group/name - [DEFAULT]/log_config
>>> #log_config_append = <None>
>>>
>>> Are you proposing removing that top line?
>>
>> That is a different type of deprecation which I didn't do a great job
>> of distinguishing.
>>
>> There is deprecation of where a config option is defined, as in your
>> example. I am not proposing to touch that at all. That simply
>> indicates that a config option used to be in a different group or
>> used to be named something else. That's very useful.
>>
>> There is deprecation of a config option in the sense that it is going
>> away completely. An example would be:
>>
>> # DEPRECATED: OpenStack metadata service manager (string value)
>> # This option is deprecated for removal.
>> # Its value may be silently ignored in the future.
>> #metadata_manager = nova.api.manager.MetadataManager
>>
>> I'm wondering if anyone sees a benefit to including that in the
>> sample file when it is clearly not meant for use.
>>
>>
>>> ___________________________________________________________________-
>>> _________
>>> 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
>>
>> ___________________________________________________________________-
>> _______
>>  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
> --
> -Dolph
> ____________________________________________________________________-
> ________
> 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/20160517/068eb812/attachment.html>