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

> On 15 Mar 2017, at 15:32, Adriano Petrich wrote: > >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 > fo

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

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,

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

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

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

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 wrote: > > > On 14 March 2017 at 11:14, Renat Akhmerov > wrote: > >> Yeah, I finally understood too what Tho

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

On 14 March 2017 at 11:14, Renat Akhmerov 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 O

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

Oh, Thanks Dougal, i am now clear since it is your TripleO use case. So yes, in this case, IMHO, we should keep the _get_client() as before but change it to the classmethod. May be other methods too like _create_client(), etc. We can think this change to be an alternative to the solution of creati

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

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) s

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

On 14 March 2017 at 10:21, lương hữu tuấn wrote: > > > On Tue, Mar 14, 2017 at 10:28 AM, Dougal Matthews > wrote: > >> >> >> On 13 March 2017 at 09:49, lương hữu tuấn wrote: >> >>> >>> >>> On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve wrote: >>> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady

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

On Tue, Mar 14, 2017 at 10:28 AM, Dougal Matthews wrote: > > > On 13 March 2017 at 09:49, lương hữu tuấn wrote: > >> >> >> On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve wrote: >> >>> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady wrote: >>> > >>> > One of the pain points for me as an action devel

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

On 14 March 2017 at 05:25, Renat Akhmerov wrote: > So again, I’m for simplicity but that kind of simplicity that also allows > flexibility in the future. > > There’s one principle that I usually follow in programming that says: > > “*Space around code (absence of code) has more potential than the

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

On 13 March 2017 at 09:49, lương hữu tuấn wrote: > > > On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve wrote: > >> On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady wrote: >> > >> > One of the pain points for me as an action developer is the OpenStack >> > actions[1]. Since they all use the same metho

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

Hi, Agree with the simplicity that Renat has shown. I would not want to change the base class as well as the way of mistral created up to now. Br, Tuan/Nokia On Mar 14, 2017 6:29 AM, "Renat Akhmerov" wrote: > So again, I’m for simplicity but that kind of simplicity that also allows > flexibil

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

So again, I’m for simplicity but that kind of simplicity that also allows flexibility in the future. There’s one principle that I usually follow in programming that says: “Space around code (absence of code) has more potential than the code itself.” That means that it’s better to get rid of any

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

On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve wrote: > On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady wrote: > > > > One of the pain points for me as an action developer is the OpenStack > > actions[1]. Since they all use the same method name to retrieve the > > underlying client, you cannot simpl

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

On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady wrote: > > One of the pain points for me as an action developer is the OpenStack > actions[1]. Since they all use the same method name to retrieve the > underlying client, you cannot simply inherit from more than one so you are > forced to rewrite the c

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

> One of the pain points for me as an action developer is the OpenStack > actions[1]. Since they all use the same method name to retrieve the > underlying client, you cannot simply inherit from more than one so you are > forced to rewrite the client access methods. We saw this in creating act

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

On Fri, Mar 10, 2017 at 5:16 AM, Renat Akhmerov wrote: > > On 10 Mar 2017, at 15:09, Dougal Matthews wrote: > > On 10 March 2017 at 04:22, Renat Akhmerov > wrote: > >> Hi, >> >> I probably like the base class approach better too. >> >> However, I’m trying to understand if we need this variety o

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

Hi, I did not know about this change before but after reading the whole story, IMHO i myself love the way of keeping it as simple at this moment as you guys i think agreed on. For MixinAction or PolicyMixin, etc. we can develop them later when we have concrete case studies. Br, Tuan/Nokia On Fr

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

> On 10 Mar 2017, at 15:09, Dougal Matthews wrote: > > On 10 March 2017 at 04:22, Renat Akhmerov > wrote: > Hi, > > I probably like the base class approach better too. > > However, I’m trying to understand if we need this variety of classes. > Do we need a sep

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

On 10 March 2017 at 04:22, Renat Akhmerov wrote: > Hi, > > I probably like the base class approach better too. > > However, I’m trying to understand if we need this variety of classes. > >- Do we need a separate class for asynchronous actions? IMO, since >is_sync() is just an instance met

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

Hi, I probably like the base class approach better too. However, I’m trying to understand if we need this variety of classes. Do we need a separate class for asynchronous actions? IMO, since is_sync() is just an instance method that can potentially return both True and False based on the instan

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

On 9 March 2017 at 17:19, Dougal Matthews wrote: > On 9 March 2017 at 04:35, Ryan Brady wrote: > >> At the PTG and previous discussions in IRC, I mentioned there were two >> different design ideas I had for the developer experience for custom action >> development in mistral-lib. The purpose an

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

On 9 March 2017 at 04:35, Ryan Brady wrote: > At the PTG and previous discussions in IRC, I mentioned there were two > different design ideas I had for the developer experience for custom action > development in mistral-lib. The purpose and intent behind the patch[1] was > discussed in person at

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

At the PTG and previous discussions in IRC, I mentioned there were two different design ideas I had for the developer experience for custom action development in mistral-lib. The purpose and intent behind the patch[1] was discussed in person at the PTG and that was helpful for me wrt to scope. I