[openstack-dev] [Oslo] Improving deprecated options identification and documentation
mzoeller at de.ibm.com
Wed Jan 20 10:04:53 UTC 2016
Ronald Bradford <me at ronaldbradford.com> wrote on 01/15/2016 03:04:29 AM:
> From: Ronald Bradford <me at ronaldbradford.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 01/15/2016 03:05 AM
> Subject: Re: [openstack-dev] [Oslo] Improving deprecated options
> identification and documentation
> On Thu, Jan 14, 2016 at 11:58 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> > On 01/14/2016 11:45 AM, Ronald Bradford wrote:
> >> Presently the oslo.config Opt class has the attributes
> >> deprecated_for_removal and deprecated_reason 
> >> I would like to propose that we use deprecated_reason (at a minimum)
> >> detail in what release an option was deprecated in, and what release
> >> is then removed in.
> > You mean what release it *will* be removed in, right? Clearly, once
> > removed, there won't be any indication it ever existed ;)
> Yes, in what release it is to be removed, e.g. Mitaka. So when is
> that release cycle, i.e. now once removed there is no record.
The information at which point in time a removal will happen can be
derived from a combination of:
* the "Deprecation Notes" (e.g. Nova's at ) and
* the "follows_standard_deprecation" policy .
I don't see the immediate need to duplicate that information.
I agree that there should be an explanation in ``deprecation_reason``
if ``deprecated_for_removal=True`` **why** we deprecated it and which
follow up actions seem to be reasonable for the ops.
 Nova's current release notes based on "reno"; "Deprecation Notes":
 OpenStack governance docs; tag "assert_follows_standard_deprecation":
Regards, Markus Zoeller (markus_z)
> > Any improvement in this regard I think would enhance the user
> > considerably, thank you Ronald for tackling this area. I'd also
> > cc'ing (or sending a separate ML post) to the openstack-operators@ ML
> > gather feedback from ops folks.
> will do!
> OpenStack Development Mailing List (not for usage questions)
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev