Open Stack

On 24/01/13 23:23, Angus Salkeld wrote:
> On 24/01/13 16:28 +0100, Zane Bitter wrote:
>>
>> 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:
>
> Yea, that's good when we started they had a clause that said you
> could only use these tools on amazon.

Ah, interesting. I wasn't aware that was a recent change, thanks!
>
> I wish they actually had a repo somewhere, but they just push out
> tarballs, someone has published a github mirror:
> https://github.com/blake-education/aws-cfn-bootstrap

Exactly, the source is now open but it is still in need of an open 
upstream project community. Which Amazon, of course, would be more than 
welcome to participate in.

(BTW I wouldn't really describe that GitHub link as a mirror - it's just 
somebody who has checked the latest tarball into git to add their own 
changes on top. There's no history of old tarballs or anything.)
>
>>
>> * Fork the aws-cfn-bootstrap tools with the goal offer 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.
>
> Not sure amazon is going to be happy about that;)

IMHO it would benefit their users, but I want to emphasize that it would 
be completely up to them how to make use of it - on no account should 
anything be pre-installed in /opt/aws without their permission. But 
that's no obstacle for Heat; we can just use cloud-init to inject a 
script to create the symlinks at boot. They can do the same, or install 
their own (we may need to rename stuff to make sure there are no 
packaging conflicts), or ask for the links to be created in the cloud 
images; I don't much care which.
>
> We could just use the "alternatives" package to switch to ours
> (ours meaning our forked version).

That's a great idea, and could work perfectly if not for the fact that 
all existing templates appear to use the fully-qualified path to call 
the scripts :/

cheers,
Zane.