openstack team mailing list archive

[Jan Drake <jan_drake@xxxxxxxxxxx>]

Brian, your two posts seem at odds with each other.

So, I've got this completely external view and possibly my own particular skew on the vision for OpenStack... specifically, I want it to isolate me from provider as much as possible.  Either I'm going to use AWS compatible interfaces for a provider or OpenStack and one has to win in the long run... okay, maybe not, maybe two co-exist as presentation layers for an internal cloud engine that's extensible middleware or some similar model.

Regardless, I want OpenStack API to run anywhere for any provider so I can choose from a marketplace of providers and have more than one PROVIDER for HA/DR reasons.  I also use the right tool for the job but when it comes to entire classes of APIs I'm going to make a business choice and... well, I'll tell ya... I'm not going to write for each provider if I can avoid it... I'm going to pick one.  I want that one to end up being OpenStack with a fan-out to whatever provider fills in the back-end (common design pattern here).

I use the right tool for the right job as well, like you mentioned in your prior post; however, I pick and make investments in platform APIs which is what OpenStack, IMNSHO, aspires to be.

I'm curious whether the product managers/owners involved think the focus should be on AWS API compatibility or whether it should be about OpenStack functionality compatibly executed on the AWS platform.  In my opinion OpenStack shouldn't be trying to be Euca and a Euca/AWS-compatible presentation layer to OpenStack is interesting but not terribly strategic.  The market is still emergent and the enterprise is the big win so... I'd let tool-switchers switch to a new, better, OS API set rather than trying to backfill a presentation layer for existing SMB market on AWS.

I'd think the Highlander approach: "There can be only one", in terms of API set, is what we'd be striving for.  

Not that I, like, have an opinion or anything.  ;)


Jan Drake


From: brian.schott@xxxxxxxxxxxxxxxxxx
Date: Sun, 10 Jul 2011 22:53:45 -0400
To: devin.carlen@xxxxxxxxx
CC: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it	worth the effort?



Devin, agree with you 100% that the EC2 and OS APIs are presentation/view layer. I also think that there is way too much view/control and policy dependencies buried down in the core nova-* services.  The core services like nova-compute shouldn't be using things like EC2 instance-id, instance-type, flavor, etc.  they should be dealing with a more abstract pool of resources hosts, instances, networks, etc.  



-------------------------------------------------Brian Schott, CTONimbis Services, Inc.brian.schott@nimbisservices.comph: 443-274-6064  fx: 443-274-6060

On Jul 9, 2011, at 8:19 PM, Devin Carlen wrote: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.


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp