[placement][ptg] code refactoring constraints and goals

Eric Fried openstack at fried.cc
Wed Apr 10 23:07:15 UTC 2019


> 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?

efried
.



More information about the openstack-discuss mailing list