openstack team mailing list archive

[Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx>]

Perhaps.  That sometimes happens when trying to make a very nuanced point :-).  I spent a lot of time hacking at nova-compute and the schemas for the heterogeneous instance types blueprint and noticed a lot of EC2-isms buried down in the code.  Even though I've been using the EC2 interface mostly and want to extend OpenStack EC2 interface support for things like cluster compute instances, I think that the low-level nova-compute service should have a higher level of abstraction about compute resources and virtual machine instances.  Pushing the OS API constraints clear down to the libvirt level and breaking EC2 is as bad as those EC2isms currently in the code.

We're in general agreement that a single auto-increment identifier doesn't scale and isn't robust. Partitioning the integer instance ids number space doesn't work if you ever expect to reconfigure your zones, merge two clouds, or do anything else that potentially causes integer partitioning to go catastrophic.  Suppose company A purchases company B and both deployments starting counting instances ids from 1.  Can you merge them without B customers losing their running instances?  You could if all openstack deployments use UUID for object identifiers.  Unless you want to go the IPv4 route....

Two big complaints in recent threads about using UUIDs for instance ids has been that 1) long strings look bad in the RESTful OS API, and 2) EC2 is only using integers how do we map, which devolved into "do we really need EC2 support"?

My question is: Why should the internal IDs used by nova-compute, nova-network, etc. to reference instance objects for VMs, volumes, network endpoints, etc. be dictated by what a human sees?  The mapping from long-form UUID to short form integer/string that the user sees is a problem for the OS/EC2 (and others if ever developed) presentation layer.  All of the internal orchestration/control logic should be using UUID exclusively.

Maybe the first-8 approach would work in both EC2 and OS API interfaces.  In the highly unlikely collision case where two different users get short-form ID i-abcdefgh from the API service, the API service resolves the ambiguity based on other context information in the call (user-id, tag/name/label, state, ...).  

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott@xxxxxxxxxxxxxxxxxx
ph: 443-274-6064  fx: 443-274-6060







On Jul 11, 2011, at 1:05 AM, Jan Drake wrote:

> 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, CTO
> Nimbis Services, Inc.
> brian.schott@xxxxxxxxxxxxxxxxxx
> ph: 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@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature