nova team mailing list archive

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

And there's a property called "name" that returns ec2_id.  So, what's the
intended semantics of id vs ec2_id?

Ewan.

> 
> I go on to say:
> 
>     Some methods here take an instance of nova.compute.service.Instance.  This
>     is the datastructure used by nova.compute to store details regarding an
>     instance, and pass them into this layer.  This layer is responsible for
>     translating that generic datastructure into terms that are specific to the
>     virtualization platform.
> 
> This can't possibly be true any longer, because nova.compute.service
> doesn't exist any more.  What is the appropriate replacement here?  I don't
> understand why the model classes in the DB layer are part of sqlalchemy,
> rather than having a model layer that's independent of the underlying DB
> technology.
> 
> Thanks,
> 
> Ewan.