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

Adriano Petrich apetrich at redhat.com
Tue Mar 14 15:14:38 UTC 2017


Sorry if I'm missing the point here, and for being late on the discussion.
But what about zope interfaces?

Would not that be clearer?



On Tue, Mar 14, 2017 at 11:39 AM, Dougal Matthews <dougal at redhat.com> wrote:

>
>
> 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
>> 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.)
>>
>
> +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
> understand.
>
>
>
>>
>>
>> Renat Akhmerov
>> @Nokia
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> 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/20170314/3eb8817a/attachment.html>


More information about the OpenStack-dev mailing list