Open Stack

Zane, thanks for writing this up, comments below..

Excerpts from Zane Bitter's message of 2013-01-24 07:28:25 -0800:
> There's been quite a bit of discussion recently about Heat's cfn-tools, 
> which currently comprise a minimalist reimplementation by the Heat 
> developers of Amazon's aws-cfn-bootstrap tools.
> 
> It was also brought up on IRC last night that there has been a formal 
> request from Amazon (not yet acted upon) for Ubuntu to include 
> aws-cfn-bootstrap in the distribution.[1]
> 
> At the same time, Fedora's Cloud SIG is discussing ways to make Fedora 
> Cloud images "more awesome".[2] Although no specifics have been 
> mentioned, packaging the aws-cfn-bootstrap tools would seem like an 
> obvious possible improvement. The Cloud SIG also has plans for Fedora 19 
> to introduce builds that target clouds other than EC2, including 
> OpenStack.[3]
> 
> Steve Hardy has done a lot of work on Heat to make the data that gets 
> passed to the instance as similar as possible to what gets passed by 
> CloudFormation (e.g. a reference to a WaitConditionHandle now resolves 
> to a pre-signed URL that can be used for signalling). Still, Heat is not 
> able to use the aws-cfn-bootstrap tools directly because they are 
> hard-coded with the CloudFormation endpoints. (There may be other issues 
> too, and more investigation is required.)
> 
> However: The aws-cfn-bootstrap tools are open source, under the Apache 2 
> license. I see little point in continuing to reimplement features 
> piecemeal as we become aware of the need for them.[4] I propose that we 
> instead take the following steps:
> 
> * Fork the aws-cfn-bootstrap tools with the goal of creating a 
> cloud-agnostic upstream community (unaffiliated with OpenStack) around them.
> * Modify the tools to read endpoints from a configuration file (perhaps 
> defaulting to the CloudFormation endpoints).
> * Make any further modifications to Heat (and/or cfn-bootstrap) required 
> to implement full interoperability.
> * Package this configurable version of aws-cfn-bootstrap for 
> Debian/Ubuntu/Fedora.
> * Work with Ubuntu and the Fedora Cloud SIG to get this configurable 
> version included in cloud server builds.
> 

This is where "Open Source" can be a trap. One has to wonder what will lag
more, the tools or the understanding of the tools and how they've changed?

There's a simple equation here. The right answer is whichever of the following
two options is lower:

* The cost of merging tools from an upstream source whose level of
cooperation is "unknown".

* the cost of implementing bits that users most desire plus the cost
of not having those features.

These are hard to measure, maybe impossible. But at least the cost of
implementing is knowable and under complete control of the Heat project.

> This would not only save us a lot of work, and likely prevent a lot of 
> bugs, but it would also offer a huge advantage to users: a single 
> prebuilt cloud image available from the distro of their choice could run 
> on both AWS and OpenStack without modification.
> 
> There is one known issue that anybody wanting to package 
> aws-cfn-bootstrap in a distro would have to circumvent: the current 
> tools are installed (appropriately) in /opt/aws/bin. Amazon, through 
> their example templates, have encouraged people to use the 
> fully-qualified path (e.g. /opt/aws/bin/cfn-init) when calling them, 
> instead of just adding /opt/aws/bin to $PATH. The latter would have made 
> the transition to including the tools in the distro (where packaging in 
> /opt is *not* appropriate) transparent, but the former most certainly 
> does not. I have several ideas for working around this, none of them good ;)
> 

The main issue seems to be that existing CloudFormation templates will
embed a single, predictable string in them, /opt/aws/bin.

Changing images is hard, but morphing templates is easy, as we control
access to them whenever they enter Heat.

what about this:

heat stack-create --aws-compat my-stack-name my-cfn-template.json

This would simply look for known issues where Heat's implementation
differs from AWS's, and fix them. So, it can remove /opt/aws/bin/, and
ensure that the Heat tools are in the path. The "How" of doing this isn't
important... what Heat users seem to desire is using the same template
on AWS and Heat.

Absent this feature..

sed -i -e 's,/opt/aws/bin/,,' my-cfn-template.json

Not nearly as cool, but probably effective for 99% of cases if the tools
are put into the system path.

I'd rather see the AWS compatibility be a little hacky than see Heat
repeat the mistakes of CloudFormation just for the sake of compatibility.
As Heat grows things that CloudFormation doesn't have, these tools will
remain extremely useful.