openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

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
>