On Tue, May 17, 2016 at 12:47 PM, Andrew Laski <and...@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 <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. > > I believe it has value still and the use case is similar. That conveys information about a feature, which I might be using, is going away. The release notes and log files provide similar info and if I saw this I'd probably head there next. If this is confusing, what if instead the warning was more strong? "this feature will not work in release X or after". Also what's the confusion issue, is it just due to a sheer number of config options to dig through as a new operator?
__________________________________________________________________________ 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