Open Stack

On 8 July 2014 01:25, Zane Bitter <zbitter at redhat.com> wrote:

> 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.
>
> (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.)
>
> 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.)
>
> +1 for idea creating new version for each release cycle. I think it will
help to modify format and additional features easier without backward
compatibility problems.

+1 for rejecting cfn functions in HOT. Sometimes it leads to confusing
situation (F.e. when user try to use Fn::GetAtt instead of get_attr in HOT,
where we have not such function).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140708/2b4f3879/attachment.html>