Open Stack

On 05/17/2016 01:47 PM, Andrew Laski 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
>> <mailto: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.

I'm +1 on removing them from sample configs.  This feels like release
note information to me, and if someone happens to miss the release note
then they'll get deprecation warnings in their logs.  The sample config
entries are redundant and just clutter things up for new deployments.

-Ben