Open Stack

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+branch:master+topic:refactor-classmethod-diaf