Open Stack

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 <mailto:dougal at redhat.com>> wrote:
> 
> 
> On 14 March 2017 at 11:14, Renat Akhmerov <renat.akhmerov at gmail.com <mailto:renat.akhmerov at 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-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@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-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/96450459/attachment.html>