Open Stack

-----Original Message-----
From: Matt Fischer <matt at mattfischer.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: May 17, 2016 at 19:29:10
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Deprecated options in sample configs?

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

Further, prior to reno, I think our release notes were more or less `git log --oneline` collections. That's rarely useful for an operator when the number of commits is very high. Hopefully with teams starting to enforce usage of reno (with the exception of a couple) operators will be able to use release notes with greater confidence and stop relying so heavily on config files. That said, old habits will be hard to break and we've encouraged/made necessary a lot of those habits over the years.

--  
Ian Cordasco