[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