Open Stack

On Mon, 2013-03-04 at 10:56 +0100, Zane Bitter wrote:
> [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?

So long as we support the other way around - i.e. the template written
against G works on H - then it's exactly what I'd expect.

It's similar to what I'd expect with e.g. Python APIs - if I want my app
to work with version 1.1 and version 1.2, then I write my app against
1.1 and assume that 1.2 is backwards compatible with 1.1.

Cheers,
Mark.