Hi Brian, I think there may be a disconnect somewhere, perhaps we have different deployments in mind or something. In my opinion, it seems we should take the fully distributed, multi-tentant route to allow peering of deployments. So whether we use UUIDs or not, the goal is to:
* Have account level namespaces. * Don't have a central authority handing out resource IDs. If you have a global namespace for a service, and anyone can peer with that service (combining global namespaces for each peer), you can purposefully create a collision. If you have account namspaces for a service, and anyone can peer with that service (combining each account namespace for each peer), you can only create collisions within a single account. With the former, you don't need access to my account to create a collision with one of my resources. With the latter, I don't need to worry about collisions from you if you don't have access to my account. Collisions are still possible within an account, so we still need to handle this case, but at least you can limit the potential damage to your account, not other tenants of the service. If this deployment is what you had in mind, please describe how a single non-centrally generated UUID could still give account-level protections. -Eric On Mon, Jul 11, 2011 at 02:09:05PM -0400, Brian Schott wrote: > Eric, > I've heard this argument before, but I don't understand how <account> > can't be injected as well to cause collisions. UUIDs can't be trusted > when user generated. As long as the UUIDs are generated consistently > across all OpenStack deployments (using the same UUID type and consistent > policy on any input parameters) they could be globally unique for all time > (in the long term, we're all dead, so close enough). > So, nova-<uuid> is sufficient. > On Jul 11, 2011, at 12:42 PM, Eric Day wrote: > > 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. > > ------------------------------------------------- > Brian Schott, CTO > Nimbis Services, Inc. > brian.sch...@nimbisservices.com > ph: 443-274-6064 fx: 443-274-6060 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp