-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/11/14 19:19, Dan Smith wrote: >>> Unfortunately this model doesn't apply to Nova objects, which >>> are persisted remotely. Unless I've missed something, SQLA >>> doesn't run on Nova Compute at all. Instead, when Nova Compute >>> calls object.save() this results in an RPC call to Nova >>> Conductor, which persists the object in the DB using SQLA. >>> Compute wouldn't be able to use common DB transactions without >>> some hairy lifecycle management in Conductor, so Compute apis >>> need to be explicitly aware of this. >> >> So just a note to Dan, this is an example of where I keep >> hearing this about Nova objects. I’ve discussed this with Dan >> and if I understand him correctly, I think the idea is that a >> Nova Compute call can be organized such that the objects layer >> interacts with the database layer in a more coarse-grained >> fashion, if that is desired, so if you really need several things >> to happen in one DB transaction, you should organize the relevant >> objects code to work that way. > > Instance.save() is a single thing. It implies that > Instance.metadata, Instance.system_metadata, Instance.info_cache, > Instance.security_groups, Instance.numa_topology, > Instance.pci_requests, etc should all be written to the database > atomically (or fail). We don't do it atomically and in a > transaction right now, but only because db/api is broken into lots > of small pieces (all of which existed before objects). > > If there was a good way to do this: > > with transaction: save_instance_data() save_instance_metadata() > save_instance_system_metadata() ...etc > > Then we'd do that at the backend, achieve atomicity, and the client > (the compute node) wouldn't notice, or care, beyond the fact that > it had assumed that was happening all along. It sounds like Mike's > facade will provide us a nice way to clean up the db/api calls that > the objects are using to persist data in such a way that we can do > the above safely like we should have been doing all along.
Agree. > > Does that make sense? > >> Still for me to get my head around is how often we are in fact >> organizing the bridge between objects / database such that we >> are using the database most effectively, and not breaking up a >> single logical operation into many individual transactions. I >> know that Nova objects doesn’t mandate that this occur but I >> still want to learn if perhaps it tends to “encourage” that >> pattern to emerge - it’s hard for me to make that guess right now >> because I haven’t surveyed nova objects very much at all as I’ve >> been really trying to stick with getting database patterns sane >> to start with. > > I don't agree that it encourages anything relating to how you > interact with the database, one way or the other. Almost all of our > objects are organized in the exact way that previously we had > dicts-of-dicts-of-dicts and an RPC call to flush things to the > database. We've changed very little of that access pattern. > > I think we should push back to Matt to provide a description of why > he thinks that this is a problem. I don't think it's a problem. It puts a practical limit on the scope of an 'api call' which can be covered by a single database transaction though, because it would be difficult to arrange for 2 RPC calls to both use the same DB transaction on the remote end. I think we agree on this. Matt - -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRlyHYACgkQNEHqGdM8NJCQsQCgmEgZGyCjIJ3zQ+mjo14AQTeo 58UAn3nhO2OfOm/xZ3yIMhlVp0EhJm+0 =xjYZ -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
