openstack team mailing list archive

["Mark Washenberger" <mark.washenberger@xxxxxxxxxxxxx>]

> 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.

This approach might help us in fixing some of the nastier bits of the openstack api images resource, as well.

"Justin Santa Barbara" <justin@xxxxxxxxxxxx> said:

> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 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@xxxxxxxxxxxxx>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@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@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
>> >
>> >
>> >_______________________________________________
>> >Mailing list: https://launchpad.net/~openstack
>> >Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> >Unsubscribe : https://launchpad.net/~openstack
>> >More help   : https://help.launchpad.net/ListHelp
>>
>>
>