nova team mailing list archive
Mailing list archive
Orm merge cleanup
Apologies, if this is a duplicate, but as far as i can tell it didn't go out the first time
So now that the orm patch is actually in, I want to mention all of the things orm related that should be cleaned up before austin. Hopefully we can have some discussion on the outstanding issues and divvy up the remaining work.
I have a whole bunch of patches ready for review based on the orm branch. Scheduler and Quota need minimal work and should be ready to be re-reviewed tomorrow.
TO BE DONE
* Xen Api
I tried to keep the changes out of the driver layer, but I suspect the changes may have broken something here, since I haven't tested it. Ewan: I hope i didn't create too much work for you here
* Flat Networking
I'm not sure if the current implementation is sufficient or if it works well for actual production. I don't know if people using flat networking want a little more automatic setup. There has also been interest in a Flat Networking + DHCP Manager. It would be great if a team who is actually using flat networking can take this over.
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()
* 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.
* 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?
* 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?
* 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'm sure there is more, but that is all that I have on the top of my head right now.