openstack team mailing list archive

[Devin Carlen <devin.carlen@xxxxxxxxx>]

On Jul 8, 2011, at 2:19 PM, Vishvananda Ishaya wrote:

> My hope was that turning ec2 into a compatibility api would force people adding the ec2 features to make them work in the openstack api as well.  I really feel like we're failing in producing a cloud standard api if we don't have all of the features.  It is quite sad that we are still missing security group support in the os api for example.

Yes - and this is a perfect example of why it's important for people to think of the EC2 and OpenStack API's not as mid-layer APIs in some stack.  These APIs are actually presentation layers.  Currently there is far too much core logic happening in the EC2 API for sure.  At this tier, there shouldn't be anything other than data transforming and API specific muck going on.

Nova is currently missing a classic middle tier, and this is why it gets difficult to circle back and add support for security groups to the OpenStack API.  There's no common layer that both APIs rely on.

This way you end up with a middle tier that is a super set of both OpenStack and EC2 APIs, and then exposing functionality in one API or the other is truly just a presentation issue, because by forcing the core to be implemented in a common layer, you force the person(s) implementing the feature to deal with the bigger picture, and not favor one API over the other.


> That said, I'm not wedded to this approach;  I don't mind ec2 talking directly to the service apis. I just want to make sure that we understand only way we are going to get to the goal of a standard ubiquitous os api is if we make sure to add the features there as well.
> 
> Said another way, I have two goals:
> 
> Goal 1. OS api becomes a complete standard that supports the entire nova feature set.
> Goal 2. EC2 api implements as close to amazon's apis as possible and supports as many features as possible without breaking compatibility.
> 
> I think that there is little disagreement in the goals, it is just how to get there that we are quibbling over.
> 
> Option 1
>    EC2
>       |
>     OS
>       |
>   Internal

This gets a huge -1 from me for the exact reasons I described above.


> Advantage: forces us to add extensions to the OS api to support ec2 features, which makes the OS api more complete.
> Disadvantage: harder to add features to the EC2 api
> 
> Option 2
>    EC2  OS
>       \      /
>      Internal
> Advantage: easier to add the ec2 features, so we end up with a more feature-rich ec2 api
> Disadvantage: OS api can get skipped when new features are added

Huge +1 here.

Like I said above, even if the OS API gets skipped in the initial implementation, that isn't as big of a deal now.  All of the core logic exists.  Now all someone has to do is expose the data transforms and API specific bits into the OS API.

The problem now is for someone to implement security groups in the OS API requires a lot of work because there's a fair amount of actual logic in the EC2 API code.

If we gave that logic a better place to live, it's far less painful to expose in multiple APIs.

> I feel that goal 1 is slightly more important than goal 2 so I'm leaning towards implementation option 1.  This is not a strong preference, though.  I think with the right focus we can achieve both goals in either scenario.


I feel very strongly that option 2 is the right move.


Devin