nova team mailing list archive

[Ewan Mellor <ewan.mellor@xxxxxxxxxxxxx>]

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>
> wrote:
> 
>   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
>   wrote:
>   >
>   > * * An instance has an ID, which is the identifier chosen by Nova to
>   represent
>   > * * 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
>   are
>   > 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
> time.
> 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
code somewhere.

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.

Cheers,

Ewan.