Open Stack

See comments in-line below.

On Mar 4, 2013, at 1:59 AM, "Zane Bitter" <zbitter at redhat.com> 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?

Validate the properties completely, and raise errors not events. Failing to do that creates a false illusion of interoperability between clouds running different template versions.

For maximum portability of templates, you want the system to allow multiple template versions to be supported simultaneously. This requires each artifact to be versioned (or the API needs to be informed of the template version upon submission) so the system can validate the template based on the stated version. If the given version is not supported on the target cloud, then reject the API call.

Adrian

> 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.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev