Re: [openstack-dev] [Mistral] ActionProvider

2014-12-19 Thread Renat Akhmerov 
Yeah,

We had a very productive discussion with Winson today and he’s going to prepare 
more formal specification on what he’s suggesting. I’d like to say in advance 
though that I really really like it in terms of what it will allow to do.

Renat Akhmerov
@ Mirantis Inc.



> On 19 Dec 2014, at 17:11, Anastasia Kuznetsova  
> wrote:
> 
> Winson, Renat,
> 
> I think that it is a good idea. Moreover, it is relevant, because about a 
> month ago there was a question from one guy in our IRC channel about what if 
> some of other 3rd party systems which provide their own client bindings (in 
> python) want to integrate with Mistral, how it will work. For that moment we 
> just thought about it, but hadn't any blueprints or discussions.
> 
> Thanks,
> Anastasia Kuznetsova
> @ Mirantis Inc.
> 
> 
> On Thu, Dec 18, 2014 at 9:33 AM, Renat Akhmerov  > wrote:
> Winson,
> 
> The idea itself makes a lot of sense to me because we’ve had a number of 
> discussions about how we could make action subsystem even more pluggable and 
> flexible. One of the questions that we’d like to solve is to be able to add 
> actions “on the fly” and at the same time stay safe. I think this whole thing 
> is about specific technical details so I would like to see more of them. 
> Generally speaking, you’re right about actions residing in a database, about 
> 3 months ago we made this refactoring and put all actions into db but it may 
> not be 100% necessary. Btw, we already have a concept of action generator 
> that we use to automatically build OpenStack actions so you can take a look 
> at how they work. Long story short… We’ve already made some steps towards 
> being more flexible and have some facilities that could be further improved.
> 
> Again, the idea is very interesting to me (and not only to me). Please share 
> the details.
> 
> Thanks
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> 
> 
> > On 17 Dec 2014, at 13:22, W Chan  > > wrote:
> >
> > Renat,
> >
> > We want to introduce the concept of an ActionProvider to Mistral.  We are 
> > thinking that with an ActionProvider, a third party system can extend 
> > Mistral with it's own action catalog and set of dedicated and specialized 
> > action executors.  The ActionProvider will return it's own list of actions 
> > via an abstract interface.  This minimizes the complexity and latency in 
> > managing and sync'ing the Action table.  In the DSL, we can define provider 
> > specific context/configuration separately and apply to all provider 
> > specific actions without explicitly passing as inputs.  WDYT?
> >
> > Winson
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Mistral] ActionProvider

2014-12-19 Thread Anastasia Kuznetsova 
Winson, Renat,

I think that it is a good idea. Moreover, it is relevant, because about a
month ago there was a question from one guy in our IRC channel about what
if some of other 3rd party systems which provide their own client bindings
(in python) want to integrate with Mistral, how it will work. For that
moment we just thought about it, but hadn't any blueprints or discussions.

Thanks,
Anastasia Kuznetsova
@ Mirantis Inc.


On Thu, Dec 18, 2014 at 9:33 AM, Renat Akhmerov 
wrote:
>
> Winson,
>
> The idea itself makes a lot of sense to me because we’ve had a number of
> discussions about how we could make action subsystem even more pluggable
> and flexible. One of the questions that we’d like to solve is to be able to
> add actions “on the fly” and at the same time stay safe. I think this whole
> thing is about specific technical details so I would like to see more of
> them. Generally speaking, you’re right about actions residing in a
> database, about 3 months ago we made this refactoring and put all actions
> into db but it may not be 100% necessary. Btw, we already have a concept of
> action generator that we use to automatically build OpenStack actions so
> you can take a look at how they work. Long story short… We’ve already made
> some steps towards being more flexible and have some facilities that could
> be further improved.
>
> Again, the idea is very interesting to me (and not only to me). Please
> share the details.
>
> Thanks
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> > On 17 Dec 2014, at 13:22, W Chan  wrote:
> >
> > Renat,
> >
> > We want to introduce the concept of an ActionProvider to Mistral.  We
> are thinking that with an ActionProvider, a third party system can extend
> Mistral with it's own action catalog and set of dedicated and specialized
> action executors.  The ActionProvider will return it's own list of actions
> via an abstract interface.  This minimizes the complexity and latency in
> managing and sync'ing the Action table.  In the DSL, we can define provider
> specific context/configuration separately and apply to all provider
> specific actions without explicitly passing as inputs.  WDYT?
> >
> > Winson
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Mistral] ActionProvider

2014-12-17 Thread Renat Akhmerov 
Winson,

The idea itself makes a lot of sense to me because we’ve had a number of 
discussions about how we could make action subsystem even more pluggable and 
flexible. One of the questions that we’d like to solve is to be able to add 
actions “on the fly” and at the same time stay safe. I think this whole thing 
is about specific technical details so I would like to see more of them. 
Generally speaking, you’re right about actions residing in a database, about 3 
months ago we made this refactoring and put all actions into db but it may not 
be 100% necessary. Btw, we already have a concept of action generator that we 
use to automatically build OpenStack actions so you can take a look at how they 
work. Long story short… We’ve already made some steps towards being more 
flexible and have some facilities that could be further improved.

Again, the idea is very interesting to me (and not only to me). Please share 
the details.

Thanks

Renat Akhmerov
@ Mirantis Inc.



> On 17 Dec 2014, at 13:22, W Chan  wrote:
> 
> Renat,
> 
> We want to introduce the concept of an ActionProvider to Mistral.  We are 
> thinking that with an ActionProvider, a third party system can extend Mistral 
> with it's own action catalog and set of dedicated and specialized action 
> executors.  The ActionProvider will return it's own list of actions via an 
> abstract interface.  This minimizes the complexity and latency in managing 
> and sync'ing the Action table.  In the DSL, we can define provider specific 
> context/configuration separately and apply to all provider specific actions 
> without explicitly passing as inputs.  WDYT?
> 
> Winson
>   
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Mistral] ActionProvider

2014-12-16 Thread W Chan 
Renat,

We want to introduce the concept of an ActionProvider to Mistral.  We are
thinking that with an ActionProvider, a third party system can extend
Mistral with it's own action catalog and set of dedicated and specialized
action executors.  The ActionProvider will return it's own list of actions
via an abstract interface.  This minimizes the complexity and latency in
managing and sync'ing the Action table.  In the DSL, we can define provider
specific context/configuration separately and apply to all provider
specific actions without explicitly passing as inputs.  WDYT?

Winson
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev