[openstack-dev] [Heat] Defining what is a SupportStatus version

Clint Byrum clint at fewbar.com
Sun Sep 14 15:09:39 UTC 2014


Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700:
> Hi,
> 
> A bit of background: I'm working on the publication of the HOT 
> resources reference on docs.openstack.org. This book is mostly 
> autogenerated from the heat source code, using the sphinx XML output. To 
> avoid publishing several references (one per released version, as is 
> done for the OpenStack config-reference), I'd like to add information 
> about the support status of each resource (when they appeared, when 
> they've been deprecated, and so on).
> 
> So the plan is to use the SupportStatus class and its `version` 
> attribute (see https://review.openstack.org/#/c/116443/ ). And the 
> question is, what information should the version attribute hold? 
> Possibilities include the release code name (Icehouse, Juno), or the 
> release version (2014.1, 2014.2). But this wouldn't be useful for users 
> of clouds continuously deployed.
> 
>  From my documenter point of view, using the code name seems the right 
> option, because it fits with the rest of the documentation.
> 
> What do you think would be the best choice from the heat devs POV?

What we ship in-tree is the standard library for Heat. I think Heat
should not tie things to the release of OpenStack, but only to itself.

The idea is to simply version the standard library of resources separately
even from the language. Added resources and properties would be minor
bumps, deprecating or removing anything would be a major bump. Users then
just need an API call that allows querying the standard library version.

With this scheme, we can provide a gate test that prevents breaking the
rules, and automatically generate the docs still. Doing this would sync
better with continuous deployers who will be running "Juno" well before
there is a "2014.2".

Anyway, Heat largely exists to support portability of apps between
OpenStack clouds. Many many OpenStack clouds don't run one release,
and we don't require them to do so. So tying to the release is, IMO,
a poor coice. We do the same thing with HOT's internals, so why not also
do the standard library this way?



More information about the OpenStack-dev mailing list