Ronald Bradford <m...@ronaldbradford.com> wrote on 01/15/2016 03:04:29 AM:
> From: Ronald Bradford <m...@ronaldbradford.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@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 <jaypi...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
