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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > wrote: > >> >> >> On 14 March 2017 at 11:14, Renat Akhmerov <[email protected]> >> 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: [email protected] >>> enstack.org?subject:unsubscribe >>> <http://[email protected]/?subject:unsubscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscrib >> e <http://[email protected]/?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
