nova team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Wed, Sep 15, 2010 at 9:59 PM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx> wrote:
> TO BE DECIDED
> - ----------------------
> * Returning linked objects from the db layer
>  There are cases where we really need to get linked objects in one query.  For example, describe_instances needs fixed and floating ips, and doing multiple trips to the database is too slow.  Right now it is returning linked objects, but we need to define somewhere how this can be returned.  It is also conceivable that we just cache in the db layer, and always use methods to retrieve linked objects -> instance_get_fixed_ip()

It's easy enough to write custom SQL in the sqlalchemy driver api.py
file.  I'm a little confused by this: "but we need to define somewhere
how this can be returned".  Could you elaborate, please?  Are you
referring to implementing lazy-loading of a model's related objects?

> * Image cleanup
> There is a commented out images model because i was assuming we want the objectstore to use the datalayer instead of json files in the filesystem.  If this is the case, someone needs to tackle this.  Another option is to just leave the images out of the datalayer until glance is finished.

For Austin?  Or Bexar?  My vote would be to leave as-is for Austin and
focus on using Glance for Bexar.  Rick and Rick, could you tell us
what the progress on Glance is and your expectations regarding getting
Glance into Austin or Bexar?  Thanks!

> * Host model
> Do we want to store data about the hosts in the datalayer?  Right now each object is just using a string where it refers to host.  This could be a foreign key if there is other data we need to store for hosts.  It would also require us deciding exactly where the host records get created.  Do we have a host_get_or_create?

>From a reporting and aggregation perspective, it would be useful to
have the Host be a full-blown model object and stored in its own
"table".  I could see a use for having aggregate or last stats info in
a Hosts table.

As far as when/where the host records get created, what about having
the scheduler be responsible for that?

> * String Ids
> There is some wonky logic in the models for converting string ids into integer ids.  Is this the best way of doing this, or should objects use a string_id as the primary key or some sort of UUID with no autoincrement.  If so how do we handle deleted objects?

Wonky indeed.

I would vastly prefer UUIDs to auto-incrementing IDs in this
particular situation where we have distributed components creating
identifiers.  Auto-increment IDs work great for centralized
datastores, but fall apart once massive scale and distributed
components come into play because of the need to have some sort of
consensus about the next identifier.  UUIDs largely sidestep these
issues.

> * Scoped Session
> Soren has suggested wrapping our session in get_session in a scoped_session, which should share one session per thread.  This seems fine, but may need a little testing to make sure it doesn't break anything

I'll wait to see the code for that one :)

-jay