Open Stack

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 [1]
> >>
> >> I would like to propose that we use deprecated_reason (at a minimum) 
to
> >> detail in what release an option was deprecated in, and what release 
it
> >> is then removed in.
> >
> >
> > You mean what release it *will* be removed in, right? Clearly, once 
it's
> > 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 [1]) and
* the "follows_standard_deprecation" policy [2].
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.

References:
[1] Nova's current release notes based on "reno"; "Deprecation Notes":
    
http://docs.openstack.org/releasenotes/nova/unreleased.html#deprecation-notes
[2] OpenStack governance docs; tag "assert_follows_standard_deprecation":
    
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
 
Regards, Markus Zoeller (markus_z)

> >
> > Any improvement in this regard I think would enhance the user 
experience
> > considerably, thank you Ronald for tackling this area. I'd also 
suggest
> > cc'ing (or sending a separate ML post) to the openstack-operators@ ML 
to
> > gather feedback from ops folks.
> >
> 
> 
> will do!
> 
> 
__________________________________________________________________________
> 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
>