← Back to team overview

openstack team mailing list archive

Re: Cross-zone instance identifiers in EC2 API - Is it worth the effort?

 

Apologies but I've been lurking on this thread and I have to agree with Devin.  What I want from Openstack APIs is a consistent API that handles the provider platform behind the scenes.  In a scenario where i need to manage aws separately, for instance, I may need openstack to expose native identifiers for debugging and extra complex management functions so I can get to that data outdide the  OStack APIs.

So, for me, I'd like to see a general pattern across openstack APIs that models and provides what I need while providing discovery interfaces for the underlying provider.



Jan Drake
Principal Cloud Architect
The Walt Disney Company

On Jul 9, 2011, at 5:23 PM, Devin Carlen <devin.carlen@xxxxxxxxx> wrote:

> Here's a few crazy questions for you guys to consider:
> 
> 1) Why are we even trying to have the same ID for an instance or image across two different APIs?
> 
> 2) How many people really switch back and forth between OpenStack and EC2 API once they pick one?
> 
> 3) How many people really expect euca2ools and python-novatools to return the same IDs for the same instances?
> 
> 4) Why not just store a EC2 ID and a OS ID alongside an actual row PK?  
> 
> 
> 
> My point with these questions is that very little is gained from forcing two different APIs to try to use the same ID, especially given that the format is different. I would argue that it has created a lot more problems than it has solved.
> 
> 
> Devin
> 
> 
> 
> On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote:
> 
>> 2011/7/8 Vishvananda Ishaya <vishvananda@xxxxxxxxx>:
>>> Yes they seem to apply to all ids
>>> r-XXXXXXX
>>> ami-XXXXXXX
>>> i-XXXXXXX
>>> vol-XXXXXXX
>>> snap-XXXXXXX
>>> 
>>> That said we are using base-36 for the hex in reservation ids and no one has complained, so i don't think they are used by the tools that much.
>> 
>> Not true. ElasticFox does not work with this.
>> 
>> I don't think we're yet at a point where we can say that lack of
>> complaints about stuff means something's fine. That sort of assumption
>> only starts to be useful when we have lots of real users. The users we
>> have so far are people who care about OpenStack for OpenStack's sake,
>> not "random" users who are being given access to an OpenStack
>> deployment and being told "talk to this like you would talk to EC2.
>> It'll work fine." Different expectations.
>> 
>> -- 
>> Soren Hansen        | http://linux2go.dk/
>> Ubuntu Developer    | http://www.ubuntu.com/
>> OpenStack Developer | http://www.openstack.org/
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 


References