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 <apetr...@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 <dou...@redhat.com > <mailto:dou...@redhat.com>> wrote: > > > On 14 March 2017 at 11:14, Renat Akhmerov <renat.akhme...@gmail.com > <mailto:renat.akhme...@gmail.com>> wrote: > Yeah, I finally understood too what Thomas meant. > > Just to clarify, I think mixed two different discussions here: > Base framework for all actions residing in mistral-lib (what I was trying to > discuss) > 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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
