openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

From: Ewan Mellor [Ewan.Mellor@xxxxxxxxxxxxx]

> If so, then I would say that your proposed limitation above is not acceptable.  We don't want a situation where tenants have to stop using the EC2 API as soon as their service provider wants to offer a rich set of offerings.

Hmm, two concerns here:

1. What's the alternative? Should we "embrace and extend" EC2 API to ensure compatibility with OS API? 

(For those not familiar with the concept http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish#The_strategy )

If so, that sounds like a bad plan since we don't have the weight or adoption to make people follow the beat of our drum (yet). It would have to be a full fork and what does that leave us with when Amazon changes the beat? ... a busted fork.

2. Could we not have plain vanilla EC2 at the top-level zone and do all the funky stuff under the hood, mapping EC2 artifacts to OS artifacts as needed? If EC2 wants 8-character with a prefix, we can map it to our UUID's across Zones, but with obvious limitations. If EC2 runs out of space in their identifiers, that's that. Either start using the OS API or use a new shard. We play the game ... to a point. When it no longer makes sense we don't try to put a square peg in a round hole. 

Same argument goes for OCCI, Bob's Cloud Mart and whatever other API's show up down the road.

At first blush I don't think there's really any reason why we can't make the top-level Zone look and feel like an EC2 deployment?

On a slightly different note (and not pointed at you Ewan :) on a suggestion from Johannes, I had a look at the Boto code base. 
https://github.com/boto/boto/tree/master/boto/ec2

It's pretty clean and only has 33 outstanding issues logged against it. If Boto was really ugly under the hood; full of patches, hacks and magic, then there may be an argument for not supporting EC2 any longer ... but it looks relatively sensible. That tells me the EC2 api isn't as bad as we're being led to believe. 

Without having an EC2 compatible API we're essentially telling AWS customers "You're stuck.  You can't have the nice toys like bursting, private deployments, choice of better-suited geographic data centers, flexible networking and volume options, design-your-own flavors, the ability to fine-tune your scheduling algorithms, quality image management, etc." 

Having EC2 API (even 80% compatible) allows them to dip their toes in the water without a large engineering effort to re-tool. Ideally, re-point their URL to a Nova install and play around. If they like what they see, they can slowly migrate away from the limitations of the EC2 world and join the party. This was the Nova vision all along, no? Incremental development vs. boil-the-ocean. As a consumer of cloud services, that sounds like a pretty compelling argument to me. 

There is another option though ... we tell customers that they have to depend on one of the many "compatibility" services that will arise. ODBC for the cloud (shudder). What's worse than yet another abstraction layer? An abstraction layer that lives in a different data center. Or we tell them to wait until a separate open source effort does the same thing? 

Perhaps I'm nuts, but I think all roads should lead to OpenStack and we should help build those roads.

-S
This email may include confidential information. If you received it in error, please delete it.