← Back to team overview

nova team mailing list archive

Re: ORM Refactor


Hi Vishy,

I'm in the process of moving nova-api off of Tornado and onto WSGI+Eventlet
(in lp:~gundlach/nova/controllers-in-api).  I'm solving the "where do we do
auth" question for you, I think -- I'm moving all the knowledge currently
contained in calls to @rbac.allow into an "ec2.Authorize" WSGI app.  It runs
after the ec2.Authenticate app (which runs the signature verification code
from the old endpoint.ApiRequestHandler) and just before the ec2.Router app
(which actually makes the call to the action and returns the XML response.)

Also, I'm very much in favor of making context into a dict of simple data --
this will hopefully make it easier to reuse code between the EC2 and
OpenStack (RS) APIs!


On Tue, Aug 31, 2010 at 8:46 PM, Vishvananda Ishaya

> 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)

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.