[openstack-dev] [mistral] Mistral Custom Actions API Design
dougal at redhat.com
Tue Mar 14 11:39:32 UTC 2017
On 14 March 2017 at 11:14, Renat Akhmerov <renat.akhmerov at gmail.com> wrote:
> Yeah, I finally understood too what Thomas meant.
> Just to clarify, I think mixed two different discussions here:
> 1. Base framework for all actions residing in mistral-lib (what I was
> trying to discuss)
> 2. 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
> 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.)
+1 to all of the above, I think we are in complete agreement and this will
give us both a flexible interface and one that is easy to use and
> Renat Akhmerov
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev