Open Stack

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

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.

--Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141113/f29d8b99/attachment.pgp>