nova team mailing list archive
Mailing list archive
Re: Instance IDs and models in the ORM world
On Mon, Oct 04, 2010 at 02:52:34PM +0100, Michael Gundlach wrote:
> Hi Ewan,
> On Sat, Oct 2, 2010 at 10:46 AM, Ewan Mellor <ewan.mellor@xxxxxxxxxxxxx>
> On Sat, Oct 02, 2010 at 03:29:57PM +0100, Ewan Mellor wrote:
> > In the documentation for the nova.virt layer (in nova.virt.fake) I
> > * * An instance has an ID, which is the identifier chosen by Nova to
> > * * the instance further up the stack. *This is unfortunately also
> called a
> > * * 'name' elsewhere. *As far as this layer is concerned, 'instance
> ID' and
> > * * 'instance name' are synonyms.
> > * * Note that the instance ID or name is not human-readable or
> > * * customer-controlled -- it's an internal ID chosen by Nova. *At the
> > * * nova.virt layer, instances do not have human-readable names at all
> -- such
> > * * things are only known higher up the stack.
> > Is this true any longer? *Looking at nova.db.sqlalchemy.Instance I see
> > fields named id, ec2_id, display_name, and display_description. *What
> > the semantics of these fields? *How far are these concepts supposed to
> > propagate down the stack?
> id is the primary key in sqlalchemy -- not stable if we move b/w databases
> or shard, so not a candidate for uniquely identifying the instance for all
> ec2_id USED TO be the string that the EC2 API used to identify the
> instance to the user.
> ec2_id is being renamed (in a branch that hasn't hit trunk yet) to
> 'internal_id' and becoming a long int. *That is the canonical identifier
> for an instance, unique for all time and unchanging throughout the life of
> the instance.
> The EC2 and Rackspace API modules convert 'internal_id' to and from an
> API-specific form suitable for showing to users -- in the EC2 case, it's
> converted to*
> **"i-%s" % base_36_representation_of(internal_id)
> I've seen some code referring to 'ec2_id' as 'instance_id' (in method
> params and such), which is just confusing; I'll be renaming those to
> internal_id for consistency before Austin.
> I don't know what display_name and display_description are about.
Thanks Michael. It would be great to see this in some doccomments in the
I agree with Jay's comments elsewhere in this thread -- it seems a better
idea to use a UUID for your internal_id, rather than a long int. That way,
the ID is an extra 64 bits longer, so you can generate them randomly on
independent nodes without worrying about collisions.