Open Stack

Yeah, I finally understood too what Thomas meant.

Just to clarify, I think mixed two different discussions here:
Base framework for all actions residing in mistral-lib (what I was trying to discuss)
The new design for OpenStack actions

On #2 I agree with you that NovaAction.get_client(context) should work. No problem with that.
And I believe that it doesn’t make sense to use multiple inheritance in this particular case, it’s
simply not worth it.

Getting back to #1.. Of course, using mixins can be problematic (method and state conflicts etc.).
I think mixins is just one of the options that’s possible to use if we want to. Regular class inheritance
is also an option I think. At this point if we just agree on action base class I think nothing prevents
us from choosing how to evolve in the future. So just agreeing on the base class design seems
to be sufficient for now. It’s just a base contract that a runner needs to be aware of (sorry for
repeating this thought but I think it’s important). The rest is related with action developer
convenience.

> I think the outstanding questions are;
> 
> - should the context be a mixin or should run() always accept context? 

I’m for run() having “context” argument. Not sure why mixin is needed here. If an action doesn’t
need context it can be ignored.

> - should async be a mixin or should we continue with the is_sync() method and overwriting that in the sublcass?

I’m for is_sync() method as it is now. It’s more flexible and less confusing (imagine an action inheriting
AsyncAction but having is_async() returning False).

> - should the openstack actions in mistral-extra be mixins?


No, not at all. They don’t have to be. This is a different discussion I think. We need to collect what’s bad about
the current OpenStack actions and think how to rewrite them (extract the common infrastructure they use,
make them more extensible, etc.)


Renat Akhmerov
@Nokia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170314/d59a32c2/attachment.html>