> One of the pain points for me as an action developer is the OpenStack 
> actions[1].  Since they all use the same method name to retrieve the 
> underlying client, you cannot simply inherit from more than one so you are 
> forced to rewrite the client access methods.  We saw this in creating actions 
> for TripleO[2].  In the base action in TripleO, we have actions that make 
> calls to more than one OpenStack client and so we end up re-writing and 
> maintaining code.  IMO the idea of using multiple inheritance there would be 
> helpful.  It may not require the mixin approach here, but rather a design 
> change in the generator to ensure the method names don't match.
> 
> [1] 
> https://github.com/openstack/mistral/blob/master/mistral/actions/openstack/actions.py
>  
> <https://github.com/openstack/mistral/blob/master/mistral/actions/openstack/actions.py>
> [2] 
> https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/base.py#L27
>  
> <https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/base.py#L27>

I think I’m ok with multiple inheritance if we have a good reason. The question 
is: do we need to have some multiple inheritance in base classes? What you’re 
saying about OpenStack actions just looks like a slightly different discussion 
because they’ve never meant to be base classes, they were not designed with 
this goal in mind. Now, when we’re refactoring the whole subsystem and also 
OpenStack actions we need to revisit their design and think how to make it more 
flexible.

My suggestion here is to move iteratively. I am personally not going to be too 
opinionated about different ideas you’re suggesting. I’d rather merge the one 
that seems the best then reevaluate, change it etc. While mistral-lib is 
considered experimental we can try different options.

Renat Akhmerov
@Nokia


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to