[placement][ptg] code refactoring constraints and goals

Jay Pipes jaypipes at gmail.com
Thu Apr 11 01:58:41 UTC 2019


On 04/10/2019 07:07 PM, Eric Fried wrote:
>> Meh :) I actually think option 1 (Do nothing) is best here.
> 
> I can live with that. But I also like what you suggested below, which is
> not "do nothing":
> 
>> from placement.objects import resource_provider
>> from placement.objects import trait
>> ...
>> # Do CRUD-y stuff with resource providers
>> rp = resource_provider.ResourceProvider(...)
>> rp.create()
>> # Do trait stuff
>> t = trait.Trait(...)
>> t.create()
>> # Do trait-y stuff with resource providers
>> rp.add_traits([t])
>> # Do search-y stuff with resource providers
>> resource_provider.get_all_by_filters(...)
>>
>> Note that the "add_traits()" is a method on the ResourceProvider object
>> in the above. I think this is more readable for create/update/delete
>> operations.
> 
> 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
> 
> How do folks feel about us making this change?

++

-jay



More information about the openstack-discuss mailing list