[openstack-dev] [Heat] Upwards compatibility in templates

Steven Dake sdake at redhat.com
Mon Mar 4 14:54:46 UTC 2013


On 03/04/2013 04:13 AM, Mark McLoughlin wrote:
> 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.

Agree

> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list