openstack team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: Paul Voccio [mailto:paul.voccio@xxxxxxxxxxxxx]
> Sent: 23 March 2011 22:19
> To: Ewan Mellor; Justin Santa Barbara; Eric Day
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Instance IDs and Multiple Zones
>
> >I don't agree at all.  There are many good reasons to preserve the
> >identity of a VM even when it's IP or location changes.  Billing, for
> >example.  Access control.  Intrusion detection.
> >
> >Just because I move a VM from one place to another, why would I expect
> >its identity to change?
> >
> >
> 
> Where do we put the boundary on the preservation of id? Within the same
> deployment? Within the same zone topology? I'm not quite following the
> billing aspect. If you shut one down and start another that is a
> problem
> for billing?
> 
> You stated earlier today:
> "We have to accept that, on the scales we care about, any unique ID is
> going to be incomprehensible to a human.  Rely on your presentation
> layer,
> that's what it's there for!"
> 
> Is this really different? If the id changes, should the user care if it is
> presented in the same way with the same data? Am I missing something?

I certainly didn't intend for those statements to be contradictory.  I don't think that they are.

My view is that identity should be preserved as long as it's possible to do so.  A VM that moves around, gets resized, gets rebooted, etc, should have the same identity.

By "identity" I mean that other pieces of software should be able to tell that it's the same thing.  A billing system should be able to say "that's the same VM that I saw before".  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.

You can invent similar arguments for penetration detection systems ("that VM is acting the way that it used to") or any other system for enforcing policy.

If you are using some kind of location- or path-based identifier for that VM, then client software has to be notified of and keep track of all the movement of the VM.  If you have a unique identifier, then clients don't have to do any of this.

My point about the UI was that we shouldn't worry about how complex these IDs should be.  We should make sure that bits of software can talk to each other correctly and simply, and base our ID scheme on those needs.  Once we've figured out what ID scheme we're using, it's _trivial_ for a UI or CLI to turn those ugly IDs into "Paul's Apache server" and "Ewan's build machine".

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?

I'm willing to accept that that's difficult to achieve, and I'd compromise on identity only being preserved within an ownership/trust boundary.  I really don't see why I should lose track of my VM when it moves from one zone to another within a given provider though.

Ewan.