Open Stack

On 10/27/2012 01:16 AM, Thierry Carrez wrote:
> Christopher B Ferris wrote:
>> Thanks for your thoughts. As for the EC2 v OpenStack APis, the EC2 API can be stripped out, leaving all functionality of nova
>> unimpaired. If the same could be true of the AWS Cloud Formation structures, it would make the project easier to consume
>> for those with persnickety legal departments.
> Indeed, Heat would basically be the first OpenStack project to adopt a
> third-party API as its main API (rather than introducing an
> OpenStack-specific API that lets us in control of the features we can
> expose).
>
> The arguments of why we need an OpenStack Compute API rather than just
> adopting the AWS EC2 API can probably be made just the same for Heat...
>
> I expect this to become a critical point in the discussion.
I think Heat has always had the intention of being driven by the needs 
of the users. Back when the project started there were no users, so a 
straw-user had to be conjured to be "Amazon CloudFormation user who 
wants to migrate to OpenStack". We have some real users doing 
interesting things now, and some interesting requests from Summit, so 
will increasingly be driven by what they are asking for.

As an example, one of the last missing CloudFormation features is Amazon 
VPC which requires some Quantum functionality that doesn't exist yet. 
However some Quantum developers liked the idea of having an entire 
quantum configuration captured in a single template file. As a 
consequence VPC will be deferred and we'll next be working on a full set 
of native Quantum resources.

Eventually we should have native resources for every OpenStack 
component. This should be easier that what we've implemented so far as 
we don't have to handle those annoying little API impedance mismatches.

cheers