> - "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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
