nova team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

I've proposed a merge of the orm refactor branch that a large part of the
nasa/anso team has been working on.  I'm hoping everyone can pick it apart
and we end up with a really clean system that everyone likes.  I've copied
the description of the change and issues below.  If the mailing list debates
get too complicated, we should just organize a time to discuss it in IRC.

Proposing merge to get feedback on orm refactoring. I am very interested in
feedback to all of these changes.

This is a huge set of changes, that touches almost all of the files. I'm
sure I have broken quite a bit, but better to take the plunge now than to
postpone this until later. The idea is to allow for pluggable backends
throughout the code.

Brief Overview
For compute/volume/network, there are multiple classes
service - responsible for rpc
  this currently uses the existing cast and call in rpc.py and a little bit
of magic
  to call public methods on the manager class.
  each service also reports its state into the database every 10 seconds
manager - responsible for managing respective object classes
  all the business logic for the classes go here
db (db_driver) - responsible for abstracting database access
driver (domain_driver) - responsible for executing actual shell commands and
implementation

Compute hasn't been fully cleaned up, but to get an idea of how it works,
take a look
at volume and network

Known issues/Things to be done:

* nova-api accesses db objects directly
  It seems cleaner to have only the managers dealing with their respective
objects. This would
  mean code for 'run_instances' would move into the manager class and it
would do the initial
  setup and cast out to the remote service

* db code uses flat methods to define its interface
  In my mind this is a little prettier as an abstract base class, but driver
loading code
  can load a module or a class. It works, so I'm not sure it needs to be
changed but feel
  free to debate it.

* Service classes have no code in them
  Not sure if this is a problem for people, but the magic of calling the
manager's methods is
  done in the base class. We could remove the magic from the base class and
explicitly
  wrap methods that we want to make available via rpc if this seems nasty.

* AuthManager Projects/Users/Roles are not integrated into this system.
  In order for everything to live happily in the backend, we need some type
  of adaptor for LDAP

* Context is not passed properly across rabbit
  Context should probably be changed to a simple dictionary so that it can
be
  passed properly through the queue

* No authorization checks on access to objects
  We need to decide on which layer auth checks should happen.

* Some of the methods in ComputeManager need to be moved into other
layers/managers
* Compute driver layer should be abstracted more cleanly
* Flat networking is untested and may need to be reworked
* Some of the api commands are not working yet
* Nova Swift Authentication needs to be refactored(Todd is working on this)