On Mon, Jul 11, 2011 at 06:31:14PM +0200, Soren Hansen wrote: > >> This is only a real problem if you insist on generating them in real > >> time rather than pre-allocate them. Each compute node could have pool > >> of thousands of ID's it could use as it pleased. That would still > >> allow for millions of compute nodes. The ID's could be centrally > >> assigned. Even if the central component that hands them out goes away, > >> a couple of thousand ID's should provide ample time for a replacement > >> to be spun up (or for the original one to come back). > > This assumes you still have something you can call "central". What > > about hybrid or peer-to-peer clouds? > > How would you share these keyspaces anyway (be they uuid, arbitratry > strings, urls, 32 bit integers, whateveR)? You can only rely on their > global uniqueness if you actually trust the entities generating them.
Agreed, anyone could inject UUIDs that collide. UUIDs alone are not sufficient, you need a namespace prefix as well (something I brought up many times before on other ID threads). The full ID needs to be something like: nova-<account>-<instance uuid> Or something along those lines (service and account/namespace can be another part of a URL, it doesn't need to be the ID string itself). Swift already does this (account/container/object), so we have a pretty good example to follow here. -Eric _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
