openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2011/7/8 Jay Pipes <jaypipes@xxxxxxxxx>:
> On Fri, Jul 8, 2011 at 9:54 AM, Soren Hansen <soren@xxxxxxxxxxx> wrote:
>> 2011/7/8 Ed Leafe <ed.leafe@xxxxxxxxxxxxx>:
>>>  No, it would work more like: a new instance is requested, and the host selected. A candidate UUID would be generated and checked for "first 8" uniqueness (I had already added a db method to locate by the first 8 chars of a UUID across nested zones). When an acceptable UUID was generated, it would be passed to the selected host along with the create request. The instance would only have to be created once.
>> If we're doing collision checking anyway, using UUID's to being with
>> is pointless. We're effectively reduced to a 32 bit key space and,
>> even worse, we're not being smart enough about it to actually do
>> without the extra DB roundtrip to check for collisions.
> That may be true, but only for the EC2 API, not the OpenStack API,
> right?

Depends. If you want to let people use either API, you need to impose
this check for objects created through the OpenStack API too,
otherwise you'll run into problems when you try to query them when
using the EC2 API.

> The question remains from my original post: do we really care
> enough about this?

Yes.

> Put another way: do we want to expend more resources on an API we don't control?

Yes.

Being able to reuse your existing tools is tremendously valuable.
Eventaully, when the OpenStack API offers compelling functionality
that you cannot get through the EC2 API, there'll be motivation for
people to switch. But even then, being able to easily start using
OpenStack and the convert to the OpenStack API piecemeal makes for a
fantastic migration path.

Until then, what exactly would be people's motivation to rework their
client tools to a different API?

-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/