Open Stack

On Wed, Mar 23, 2011 at 09:15:38PM -0400, Ed Leafe wrote:
> On Mar 23, 2011, at 8:59 PM, Eric Day wrote:
> 
> > May I ask what is the point of doing this if it won't make cactus and
> > we're just going to replace it in a month or two? I think we all agree
> > that 64-bit integer IDs are insufficient for multi-zone deployments,
> > so no one will be deploying this until we sort it out and come up
> > with a better ID.
> 
> 
> 	Because this is just one part of the process of creating a distributed scheduler. The process for selecting a host for a new instance won't depend on the type of PK used for that instance in a db table.

Sure, selecting a host for new instances doesn't depend on solving
the unique ID issue either. You can still work on this without the
partitioning, no?

It's only once the instance is created and we need to list and route
subsequent requests does the uniqueness issue (and ID type) come
up. For this I'm asking why bother implementing partitioning that
will be thrown away if we can finish working through a more robust
path and start working on that?

> 	The only reason I brought it up was that Sandy pointed out this uniqueness requirement, and we felt it would be a good idea to ask the list if they had any good ideas about alternatives to range partitions.

Yeah, and this is an important issue we need to solve soon for the
multi-zone work.

> I prefaced my initial post with a disclaimer that I wasn't looking to re-argue things that had already been discussed and agreed to, but I guess most people missed that part. :)

I don't think anyone is arguing, all the discussion has been very
healthy IMHO. We've also not previously discussed or decided anything
at the multi-zone level either (at least nothing I was aware of),
only ID's within a zone.

I think all this is new and useful discussion. :)

-Eric