[openstack-dev] [mistral] Mistral Custom Actions API Design

lương hữu tuấn tuantuluong at gmail.com
Mon Mar 13 09:49:12 UTC 2017


On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve <therve at redhat.com> wrote:

> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady <rbrady at redhat.com> wrote:
> >
> > 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.
>
> Is there any reason why those methods aren't functions? AFAICT they
> don't use the instance, they could live top level in the action module
> and be accessible by all actions. If you can avoid multiple
> inheritance (or inheritance!) you'll simplify the design. You could
> also do client = NovaAction().get_client() in your own action (if
> get_client was a public method).
>
> --
> Thomas
>
> If you want to do that, you need to change the whole structure of base
action and the whole way of creating an action
as you have described and IMHO, i myself do not like this idea:

1. Mistral is working well (at the standpoint of creating action) and
changing it is not a short term work.
2. Using base class to create base action is actually a good idea in order
to control and make easy to action developers.
The base class will define the whole mechanism to execute an action,
developers do not need to take care of it, just only
providing OpenStack clients (the _create_client() method).
3. From the #2 point of view, the alternative to NovaAction().get_client()
does not make sense since the problem here is subclass mechanism,
not the way to call get_client().

@Renat: I myself not against to multiple inheritance too, the only thing is
if we want to make it multiple inheritance, we should think about it more
thoroughly for the hierarchy of inheritance, what each inheritance layer
does, etc. These work will make the multiple inheritance easy to understand
and for action developers as well easy to develop. So, IMHO, i vote for
make it simple, easy to understand first (if you continue with mistral-lib)
and then do the next thing later.

Br,

Tuan/Nokia

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170313/51797647/attachment.html>


More information about the OpenStack-dev mailing list