[openstack-dev] [Oslo] Improving deprecated options identification and documentation

Ronald Bradford me at ronaldbradford.com
Wed Jan 20 18:34:07 UTC 2016


> > 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.
The potential duplication you refer to enables code scanning/automation to
detect and even initiate steps at the start of a release cycle to remove
deprecated options.
Looking at documented notes is a more inconsistent manual approach. The
number of deprecated options should not be high, I do not see the issue in
ensuring this information is in code as well as docs.

> 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.
Thanks!  I think for now, stating a reason, stating what release it was
deprecated and what release it should be removed provides a starting point
with a low barrier of entry to see results.

Ronald (rbradfor)

> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160120/dcc97487/attachment-0001.html>

More information about the OpenStack-dev mailing list