Open Stack

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."

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160517/4b3b4460/attachment.html>