Open Stack

Thanks for the clarification. I wasn't sure if you were actually
contradicting yourself as it seemed such an odd thing for you to do. : )

More below!


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

Thanks for the clarification. I wasn't sure if you were actually
contradicting yourself as it seemed such an odd thing for you to do. : )


>
>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-ra
>ckspace-cloud-servers-changing-from-hourly-to-monthly/), not just a
>corner-case example.

I can speak to this particular example as it only charges you for the max
number of RedHat vms you run for the month. With the caveat of this is how
it was explained to me, please consider the scenario:

Launch 2, 
Terminate 2
Launch 5
Terminate 2
Launch 3 
Terminate All

You get billed for the hours plus 6 RHEL licenses since that was your
peak. In your example above, if you terminated then started another
instance, that¹s really 2 instances, with only one active at any time. If
you launched one with cloned data from the other one and both are active
at the same time, its really a additional instance and the operator can
bill accordingly. I don't suppose this really matters for the point your
making and I'll concede that.

>
>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".
I would agree with this.

>
>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?

Is it the ID that matters or the data inside the vm? I think its really
about the data. Consistent Ids would be nice though.

>
>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.

If we were to go with UUIDs and using XenServer, I should be able to use
the uuid that it generates upon VM creation. I would almost ask your above
question for XenServer then. When I terminate and launch an VM on the same
machine, I should be able to give it the same uuid that I was just using,
but I can't. Maybe I can and I'm making it harder on myself :)

pvo


>
>Ewan.
>



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 at rackspace.com, and delete the original message.
Your cooperation is appreciated.