Open Stack

I'd like to point out that while I agree with moving to strings (and
using UUIDs as internal identifiers), this is a discussion for the
summit, and under no circumstances should anyone get the impression
that a change to the identifier will be occurring for Cactus!

-jay

On Tue, Mar 22, 2011 at 4:06 PM, Justin Santa Barbara
<justin at fathomdb.com> wrote:
> 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
>>>
>>
>>
>
>
> _______________________________________________
> 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
>
>