Open Stack

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