Open Stack

Renat,

   I was talking to some friends that have more (and more recent)
experience with standalone zope.interfaces inside other projects (last time
I used it was inside zope and 10 years ago) and I think it might be just
overcomplexity for our task at hand.

   Cheers,
  Adriano

On Wed, Mar 15, 2017 at 7:05 AM, Renat Akhmerov <renat.akhmerov at gmail.com>
wrote:

> Well, zope is a cool thing I believe. We can consider to use it. I just
> don’t see what real advantage it’ll give us now.
> Essentially, what we’re trying to do now is pretty simple. We’re just
> defining one base class for all actions w/o talking
> about various modifications of this class yet.
>
> So if you see a concrete idea about using zope interfaces please share.
> I’m interested in that.
>
> Renat Akhmerov
> @Nokia
>
> On 14 Mar 2017, at 22:14, Adriano Petrich <apetrich at redhat.com> wrote:
>
> 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.op
>>> enstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> 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:unsubscrib
>> e <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> 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
>
>
>
> __________________________________________________________________________
> 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/20170315/64cf6f8c/attachment.html>