On Tue, May 17, 2016, at 02:36 PM, Matt Fischer wrote: > On Tue, May 17, 2016 at 12:25 PM, Andrew Laski > <and...@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- > requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
