openstack team mailing list archive
Mailing list archive
Re: Instance IDs and Multiple Zones
From: Ewan Mellor [Ewan.Mellor@xxxxxxxxxxxxx]
> For example, if I charge my customers for a month of usage, even if they only run the VM for a part of that month, then my billing system needs to be able to say "that VM has moved from here to here, but it's actually the same VM, so I'm charging for one month, not two". This is the current charging scheme for RHEL instances hosted on Rackspace Cloud (http://www.rackspace.com/cloud/blog/2010/08/31/red-hat-license-fee-for-rackspace-cloud-servers-changing-from-hourly-to-monthly/), not just a corner-case example.
Good use cases.
> To your point about the boundary of preservation of ID, that's a good question. If you ignore the security / trust issues, then the obvious answer is that IDs should be globally, infinitely, permanently unique. That's what UUIDs are for. We can generate these randomly without any need for a central authority, and with no fear of collisions. It would certainly be nice if my VM can leave my SoftLayer DC and arrive in my Rackspace DC and when it comes back I still know that it's the same VM. That's the OpenStack dream, right?
Hmm, I may have been swayed against UNC. Routing and caching can still be layered on a UUID without having to parse it.
Mailing list: https://launchpad.net/~openstack
Post to : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.