Open Stack

Excerpts from Zane Bitter's message of 2014-07-07 14:25:50 -0700:
> With the Icehouse release we announced that there would be no further 
> backwards-incompatible changes to HOT without a revision bump. However, 
> I notice that we've already made an upward-incompatible change in Juno:
> 
> https://review.openstack.org/#/c/102718/
> 
> So a user will be able to create a valid template for a Juno (or later) 
> version of Heat with the version
> 
>    heat_template_version: 2013-05-23
> 
> but the same template may break on an Icehouse installation of Heat with 
> the "stable" HOT parser. IMO this is almost equally as bad as breaking 
> backwards compatibility, since a user moving between clouds will 
> generally have no idea whether they are going forward or backward in 
> version terms.

Sounds like a bug in Juno that we need to fix. I agree, this is a new
template version.

> 
> (Note: AWS don't use the version field this way, because there is only 
> one AWS and therefore in theory they don't have this problem. This 
> implies that we might need a more sophisticated versioning system.)
> 

A good manual with a "this was introduced in version X" and "this was
changed in version Y" would, IMO be enough, to help users not go crazy
and help us know whether something is a bug or not. We can probably
achieve this entirely in the in-code template guide.

> I'd like to propose a policy that we bump the revision of HOT whenever 
> we make a change from the previous stable version, and that we declare 
> the new version stable at the end of each release cycle. Maybe we can 
> post-date it to indicate the policy more clearly. (I'd also like to 
> propose that the Juno version drops cfn-style function support.)

Agreed. I'm also curious if we're going to reject a template with
version 2013-05-23 that includes list_join. If we don't reject it, we
probably need to look at how to show the user warnings about
version/feature skew.