On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote: > > It seems I've talked myself into preferring option e). It's too much > work to do on my own, though, and it's going to be disruptive, so we > need to do it real soon. I think it'll be worth it, though.
I agree. This will also make it easier to swap out the storage with other Non-SQLAlchemy datastores *cough* ElasticSearch *cough*. On the network side of things, I've spend the last few weeks "untie-ing" network FK's and joinloads for the untie-nova-network-models blueprint. Those will be merge prop'd as soon as I get some merge conflicts squared away. Also Trey is working on a standardized "Network Model" objects that is really just a dict++ so serialization is easy. Our plan on in the network fiefdom is to pass around only these objects eventually to get us off relying on the underlying SQLAlchemy objects. Happy Hacking! 7-11 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
