Open Stack

[Taking this to openstack-dev, because I think it's an important discussion]

There's a debate going on in https://review.openstack.org/23157 
regarding to what extent we should try to handle upwards compatibility 
of templates in Heat. The issue in question is how to handle Resource 
properties that are not defined. At present, this is almost always due 
to a typo on the part of the template creator, and it would be highly 
desirable to return an error (as AWS does). On the other hand, this may 
not always be the case if we add properties to resources in future.

As I wrote in a review comment, let us say that cloud provider G rolls 
out a Grizzly-based OpenStack cloud, and then later cloud provider H 
rolls out a Havana-based cloud, where we've added a bunch of properties 
to resources. Templates written for cloud provider H that use these 
properties will now fail to launch on cloud provider G if we strictly 
enforce properties. This is a problem that AWS does not have. The 
question is, do we care?

On 04/03/13 09:53, Steven Hardy wrote:
> Patch Set 1:
>
>> One argument would be that the property is obviously added to mean something, so if we can't handle it we should fail and make the user edit his template.
>
> This - it then makes it obvious to the user that certain features aren't supported (or that they have typos in their template, which this patch will make totally non-obvious).
>
> Versioning the templates is better handled either by the user using traditional tools, git etc, or via versioning at the API level IMO.
>
>> Another argument would be that we should make it possible for automated tools to shift templates between cloud providers without editing or necessarily moving to lowest-common-denominator templates.
>
> So to me this implies either versioning of templates via specific API versions (which we obviously already have but it doesn't translate into versioned resource schema's AFAICS), or some migration/compatibility tool/script above the API which knows about the various template versions.

Versioning templates helps a lot with backwards-compatibility, but can 
be hard with upwards-compatibility unless you know what kind of changes 
you will be making. (This would probably work if we rolled out all 
changes like this one release in advance, but we probably don't want to 
do that.)

> I don't think implementing a permissive "accept everything" policy in the engine is compatible with either approach.


It's worth noting that currently we report an error if a template uses a 
property that is defined by CloudFormation but not (yet) supported by 
Heat. So consistency would argue in favour of Steve's approach (i.e. 
returning an error).

Here's one option I just thought of: adding a property definition to a 
resource is just a single line of code. In the event of adding one, we 
could backport the definition (but not necessarily the implementation) 
of the property to previous stable branches. That way it will work so 
long as your cloud provider is up to date with the stable branch (and if 
they're not, you should probably run away screaming anyhow).

I also like the idea of providing an automated tool for converting 
between versions. It would be helpful to have something like that anyway 
for converting from YAML templates (we have this already) with some of 
the future features we might add (such as 
https://blueprints.launchpad.net/heat/+spec/bash-environment-function) 
back to CloudFormation-compatible JSON templates. Perhaps we could even 
make this part of the ReST API?

cheers,
Zane.