I was actually starting to explore
This suggests a change whereby we move a bunch of module-level methods to instance methods. I actually really like that idea. So for example:
@db_api.placement_context_manager.writer def _set_traits(context, rp, traits): ...
becomes:
class ResourceProvider(object): ... @db_api.placement_context_manager.writer def _set_traits(self, traits): ... # the artist formerly known as 'rp' is now 'self' # and context is self._context
and
For a variety of reasons, most of which would be obvious given my previous enthusiasm for exploring alternatives, I’ve proposed a story for refactoring out the DB-specific code from the rest of placement:
https://storyboard.openstack.org/#!/story/2005435
I don’t know what everyone’s preference would be for where the DB code would go: either in private methods of the original module, or in a separate DB module, so I added as the first task coming to a decision on how to make that split.
, planning to propose them both as parallel changes/series so we could see how they look IRL. In the process, I discovered a remaining @classmethod in resource_provider.py, which I figured should be taken care of first, so I moved it. And then looked for other @classmethodZ, because. And ended up with [1], which removes all @classmethodZ from the project, in keeping with what seems to be the majority's desire. I'm going to fork another response to this thread to report on some stuff I discovered on the original two proposals... efried [1] https://review.openstack.org/#/q/status:open+project:openstack/placement+bra...