Open Stack

On 05/17/2016 07:27 PM, Matt Fischer wrote:
>      
>     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.
> 
> 
> 
> One way to think about this is that the config file has to be accurate
> or the code won't work, but release notes can miss things with no
> consequences other than perhaps an annoyed operator. So they are sources
> of truth about the state options on of a release or branch.

On this note, I had another thought about an alternative way to handle
this.  What if we generated one sample file without deprecated opts, and
another with them (either exclusively, or in addition to all the other
opts)?  That way there's a deprecation-free version for new deployers
and one for people who want to see all the current deprecations.

>  
> 
>      
>     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.
> 
> 
> It's always good to have these kind of conversations, thanks for
> starting it. 
> 
> 
> 
> __________________________________________________________________________
> 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
>