Open Stack

Let's take a leadership position here and go with strings; we're not
breaking Amazon's API.  AWS will have to make the same changes when they
reach our scale and ambition :-)

We should also start engaging with client tools, because we're never going
to be 100% EC2 compatible.  At the least, our endpoints will be different.

I think we should discuss this at the Design Summit, and then make an effort
on this front as part of Diablo.



On Tue, Mar 22, 2011 at 12:58 PM, Vishvananda Ishaya
<vishvananda at gmail.com>wrote:

> Yes, that is what they say,  Unfortunately all of the ec2 tools expect the
> current format that they are using to various degrees.
>
> Some just need the proper prefix (euca2ools)
> Others need the prefix + hex (elasticfox, irrc)
> Others allow a string but limit it to 11 chars, etc.
>
> So to keep compatibility we are stuck mimicking amazon's string version for
> now.
>
> Vish
>
> On Mar 22, 2011, at 12:51 PM, Justin Santa Barbara wrote:
>
> EC2 uses xsd:string for their instance id.  I can't find any additional
> guarantees.
>
> Here's a (second hand) quote from Amazon:
>
>
> http://serverfault.com/questions/58401/is-the-amazon-ec2-instance-id-unique-forever
> "Instance ids are unique. You'll never receive a duplicate id. However, the
> current format of the instance id is an implementation detail that is
> subject to change. If you use the instance id as a string, you should be
> fine."
>
> So, strings it is then? :-)
>
>
>
> On Tue, Mar 22, 2011 at 12:44 PM, Vishvananda Ishaya <
> vishvananda at gmail.com> wrote:
>
>> The main issue that drove integers is backwards compatibility to the
>> ec2_api and existing ec2 toolsets.  People seemed very opposed to the idea
>> of having two separate ids in the database, one for ec2 and one for the
>> underlying system.  If we want to move to another id scheme that doesn't fit
>> in a 32 bit integer we have to provide a way for ec2 style ids to be
>> assigned to instances, perhaps through a central authority that hands out
>> unique ids.
>>
>> Vish
>>
>> On Mar 22, 2011, at 12:30 PM, Justin Santa Barbara wrote:
>>
>> The API spec doesn't seem to preclude us from doing a fully-synchronous
>> method if we want to (it just reserves the option to do an async
>> implementation).  Obviously we should make scheduling fast, but I think
>> we're fine doing synchronous scheduling.  It's still probably going to be
>> much faster than CloudServers on a bad day anyway :-)
>>
>> Anyone have a link to where we chose to go with integer IDs?  I'd like to
>> understand why, because presumably we had a good reason.
>>
>> However, if we don't have documentation of the decision, then I vote that
>> it never happened, and instance ids are strings.  We've always been at war
>> with Eastasia, and all ids have always been strings.
>>
>> Justin
>>
>>
>>
>>
>> On Tue, Mar 22, 2011 at 12:20 PM, Paul Voccio <paul.voccio at rackspace.com>wrote:
>>
>>> I agree with the sentiment that integers aren't the way to go long term.
>>> The current spec of the api does introduce some interesting problems to
>>> this discussion. All can be solved. The spec calls for the api to return
>>> an id and a password upon instance creation. This means the api isn't
>>> asynchronous if it has to wait for the zone to create the id. From page
>>> 46
>>> of the API Spec states the following:
>>>
>>> "Note that when creating a server only the server ID and the admin
>>> password are guaranteed to be returned in the request object. Additional
>>> attributes may be retrieved by performing subsequent GETs on the server."
>>>
>>>
>>>
>>> This creates a problem with the bursting if Z1 calls to Z2, which is a
>>> public cloud, which has to wait for Z3-X to find out where it is going be
>>> placed. How would this work?
>>>
>>> pvo
>>>
>>> On 3/22/11 1:39 PM, "Chris Behrens" <chris.behrens at rackspace.com> wrote:
>>>
>>> >
>>> >I think Dragon got it right.  We need a zone identifier prefix on the
>>> >IDs.  I think we need to get away from numbers.  I don't see any reason
>>> >why they need to be numbers.  But, even if they did, you can pick very
>>> >large numbers and reserve some bits for zone ID.
>>> >
>>> >- Chris
>>> >
>>> >
>>> >On Mar 22, 2011, at 10:48 AM, Justin Santa Barbara wrote:
>>> >
>>> >> I think _if_ we want to stick with straight numbers, the following are
>>> >>the 'traditional' choices:
>>> >>
>>> >> 1) "Skipping" - so zone1 would allocate numbers 1,3,5, zone2 numbers
>>> >>2,4,6.  Requires that you know in advance how many zones there are.
>>> >> 2) Prefixing - so zone0 would get 0xxxxxxx, zone1 1xxxxxx.
>>> >> 3) Central allocation - each zone would request an ID from a central
>>> >>pool.  This might not be a bad thing, if you do want to have a quick
>>> >>lookup table of ID -> zone.  Doesn't work if the zones aren't under the
>>> >>same administrative control.
>>> >> 4) Block allocation - a refinement of #3, where you get a bunch of
>>> IDs.
>>> >> Effectively amortizes the cost of the RPC.  Probably not worth the
>>> >>effort here.
>>> >>
>>> >> (If you want central allocation without a shared database, that's also
>>> >>possible, but requires some trickier protocols.)
>>> >>
>>> >> However, I agree with Monsyne: numeric IDs have got to go.  Suppose
>>> I'm
>>> >>a customer of Rackspace CloudServers once it is running on OpenStack,
>>> >>and I also have a private cloud that the new Rackspace Cloud Business
>>> >>unit has built for me.  I like both, and then I want to do cloud
>>> >>bursting in between them, by putting an aggregating zone in front of
>>> >>them.  I think at that stage, we're screwed unless we figure this out
>>> >>now.  And this scenario only has one provider (Rackspace) involved!
>>> >>
>>> >> We can square the circle however - if we want numbers, let's use UUIDs
>>> >>- they're 128 bit numbers, and won't in practice collide.  I'd still
>>> >>prefer strings though...
>>> >>
>>> >> Justin
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Mar 22, 2011 at 9:40 AM, Ed Leafe <ed at leafe.com> wrote:
>>> >>        I want to get some input from all of you on what you think is
>>> >>the best way to approach this problem: the RS API requires that every
>>> >>instance have a unique ID, and we are currently creating these IDs by
>>> >>use of an auto-increment field in the instances table. The introduction
>>> >>of zones complicates this, as each zone has its own database.
>>> >>
>>> >>        The two obvious solutions are a) a single, shared database and
>>> >>b) using a UUID instead of an integer for the ID. Both of these
>>> >>approaches have been discussed and rejected, so let's not bring them
>>> >>back up now.
>>> >>
>>> >>        Given integer IDs and separate databases, the only obvious
>>> >>choice is partitioning the numeric space so that each zone starts its
>>> >>auto-incrementing at a different point, with enough room between
>>> >>starting ranges to ensure that they would never overlap. This would
>>> >>require some assumptions be made about the maximum number of instances
>>> >>that would ever be created in a single zone in order to determine how
>>> >>much numeric space that zone would need. I'm looking to get some
>>> >>feedback on what would seem to be reasonable guesses to these partition
>>> >>sizes.
>>> >>
>>> >>        The other concern is more aesthetic than technical: we can make
>>> >>the numeric spaces big enough to avoid overlap, but then we'll have
>>> very
>>> >>large ID values; e.g., 10 or more digits for an instance. Computers
>>> >>won't care, but people might, so I thought I'd at least bring up this
>>> >>potential objection.
>>> >>
>>> >>
>>> >>
>>> >> -- Ed Leafe
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>>
>>>
>> _______________________________________________
>> 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/20110322/d9710950/attachment.html>