Open Stack

> - "fat model" approach - put the db interaction in objects

If it's just DB interaction, then yes, in the object for sure.

> - put the db interactions in the conductor itself

There is a reasonable separation between using conductor for mechanics
(i.e. API deferring a long-running activity to conductor) and using it
for (new) DB proxying. At this point. the former is okay and the latter
is not, IMHO.

That said, any complex data structure going over RPC should be an object
as well, so that we have version tracking on the structure itself. We
recently had a case where we broke upgrades because the *format* of an
RPC method argument was changed, that argument was not an object, and we
ended up with some very ugly failures as a result :)

--Dan