Apologies, if this is a duplicate, but as far as i can tell it didn't go out the first time
Hi Everyone, 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. _______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
