<div dir="ltr">Winson, Renat,<div><br></div><div>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.<br></div><div><br></div><div>Thanks,</div><div>Anastasia Kuznetsova</div><div>@ Mirantis Inc.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 18, 2014 at 9:33 AM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Winson,<br>
<br>
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.<br>
<br>
Again, the idea is very interesting to me (and not only to me). Please share the details.<br>
<br>
Thanks<br>
<br>
Renat Akhmerov<br>
@ Mirantis Inc.<br>
<div><div class="h5"><br>
<br>
<br>
> On 17 Dec 2014, at 13:22, W Chan <<a href="mailto:m4d.coder@gmail.com">m4d.coder@gmail.com</a>> wrote:<br>
><br>
> Renat,<br>
><br>
> 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?<br>
><br>
> Winson<br>
><br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>