Open Stack

> 1) Done right, the only time I need native IDs is when I have a complex situation which needs debugging.  It isn't the norm (or if it is, we've failed) -- so really I ONLY need native IDs when it's all gone pear shaped.

Speak for yourself!  I debug complex situations every day.  Sure, I don't expect my end users to be doing that every day, because I expect to have shipped them production-quality code.  For my own sanity, I would like the system as simple as possible.

> 2) Multi-API integration is (see point above) a secondary or tertiary set of use cases.  Consider using discovery pattern for those integrations rather than trying to shove them as primary into the OS interfaces... which will only
> end in maddening disaster after you add more than AWS in terms of required support.  A general pattern for native discovery in these exception cases needs to be the focus.

I have no idea what you're trying to say here.  Could you try again?

> 3) We fail if we put native debugging capability in front of properly architected and designed OS API semantics

Nobody did, did they?  We are all trying very hard to make the OpenStack API the best that it can be.

> 4) Performance benefits?  You need to convince me the transaction rate capability is seriously impacted on string vs guid implementations.  Sorry, but doubtful.  (mea culpa: I am not familiar with implementation details of this
> context but still..)

No, not string vs guid.  Current AWS IDs are 32 bits.  Being a small key space, this means that you either need to allocate them incrementally (implying a distributed transaction across the incrementer) or you need to perform a collision detection (implying a distributed transaction across the database, or maybe even all the databases in all the zones).

UUIDs, being 128 bits, can be allocated randomly without fear of collisions, which means you can do it even before you've been anywhere near the database.

> We all need to get out of reactive, myopic, API-to-API-parity mode and into OpenStack centric API capability mode.

I don't want the OpenStack API to aim for feature parity with the AWS API.  I said that elsewhere in this thread.  I don't think anyone who's working on the OpenStack API wants that.  We all agree that the OpenStack API is there so that we can innovate around the API, and add new features to the platform as quickly as possible.  That's a primary goal for the whole project.

All we're trying to do is to figure out a way to do that while leveraging a large ecosystem of existing tools, so that people can get onto OpenStack as painlessly as possible.

Cheers,

Ewan.


From: Jan Drake [mailto:jan_drake at hotmail.com]
Sent: 11 July 2011 01:44
To: Ewan Mellor; devin.carlen at gmail.com; soren at linux2go.dk
Cc: chris.behrens at rackspace.com; ed.leafe at rackspace.com; openstack at lists.launchpad.net
Subject: RE: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

First, y'all need to remember that it isn't just AWS... it's N systems that back-end OS API over time.

Ewan, I understand your intent, but it is a bit myopic:

1) Done right, the only time I need native IDs is when I have a complex situation which needs debugging.  It isn't the norm (or if it is, we've failed) -- so really I ONLY need native IDs when it's all gone pear shaped.

2) Multi-API integration is (see point above) a secondary or tertiary set of use cases.  Consider using discovery pattern for those integrations rather than trying to shove them as primary into the OS interfaces... which will only end in maddening disaster after you add more than AWS in terms of required support.  A general pattern for native discovery in these exception cases needs to be the focus.

3) We fail if we put native debugging capability in front of properly architected and designed OS API semantics

4) Performance benefits?  You need to convince me the transaction rate capability is seriously impacted on string vs guid implementations.  Sorry, but doubtful.  (mea culpa: I am not familiar with implementation details of this context but still..)

Look, as an API user... frankly, I don't want to manage complexity across providers.  The more OS can insulate me from the details while providing equivalent functionality the better.  And quickly, please.

I'm rather interested in betting a whole company on an API that groks that value equals maximum insulation from native platforms while giving me 80% plus of capabilities across all native platforms... and APIs to support exploration and integration for the 20% that I invest in.

We all need to get out of reactive, myopic, API-to-API-parity mode and into OpenStack centric API capability mode.

OpenStack will win on ubiquity of cloud capability not on API/feature parity with whomever is out there.

This is my final post on this topic here.  I'll be focusing on other topics but I'm glad this gave the opportunity to share the perspective I have and I very much desire further conversation along any dimension at jan_drake at hotmail.com.

I'd value key architects for OS reaching out to me on this and other topics.

Jan Drake
> From: Ewan.Mellor at eu.citrix.com
> To: devin.carlen at gmail.com; soren at linux2go.dk
> Date: Mon, 11 Jul 2011 06:43:32 +0100
> CC: chris.behrens at rackspace.com; ed.leafe at rackspace.com; openstack at lists.launchpad.net
> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
>
> > From: Devin Carlen
> >
> > 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?
>
> To reduce complexity (particularly when trying to debug the system as a whole).
>
> > 2) How many people really switch back and forth between OpenStack and
> > EC2 API once they pick one?
>
> This will be very common. We're going to have UIs that use the OpenStack API, monitoring systems that use the EC2 API, CLIs using either, all in use on the same cloud, by the same users, at the same time.
>
> Also, the multi-zone support is built using the OpenStack API, and the Quantum integration will no doubt use it too, so in reality any use of the EC2 API at all is going to give us a multi-API cloud.
>
> > 3) How many people really expect euca2ools and python-novatools to
> > return the same IDs for the same instances?
>
> It sure would make it a lot easier to debug!
>
> > 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.
>
> This is certainly a possibility. The problem with this is you have to do the central allocation for the EC2 ID, so you destroy the performance benefits of using a UUID.
>
> I could imagine a scheme where the EC2 ID was lazily generated, so you didn't allocate one unless that API was used. That would meet all of _my_ requirements, I think (I'm not sure about anyone else's). The downside with that is it's more complicated, of course.
>
> Ewan.
>
>
> >
> >
> > Devin
> >
> >
> >
> > On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote:
> >
> > > 2011/7/8 Vishvananda Ishaya <vishvananda at gmail.com>:
> > >> 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 at lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~openstack
> > > More help : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110711/1d25eee3/attachment.html>