Or, feel free to join our IRC channel for quick response, #openstack-mistral
On Tue, Oct 20, 2015 at 4:58 PM, WANG, Ming Hao (Tony T) <tony.a.w...@alcatel-lucent.com> wrote: > Renat, > > > > Another question is: > > If I use custom action to run Ansible, the Ansible playbook should be stored > on the same server of Mistral. Is it right? > > > > Thanks, > > Tony > > > > From: Renat Akhmerov [mailto:rakhme...@mirantis.com] > Sent: Monday, October 19, 2015 2:58 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [mistral] How to call 3rd-party tools(such as > Ansible) in Mistral > > > > > > On 19 Oct 2015, at 07:53, WANG, Ming Hao (Tony T) > <tony.a.w...@alcatel-lucent.com> wrote: > > > > The “custom action” needs to re-install Mistral. > > If the Mistral service is part of 3rd party OpenStack, it may be > unacceptable to let every user create his own customer action. What do you > think? > > > > Yes, correct. It requires reinstall. If your goal is to give users > possibility to create custom actions "on the fly” then it’s now impossible > in Mistral for fundamental reasons. We can’t let users upload arbitrary > Python code via API for security reasons. However, we have a couple of ideas > that we’re going to explore in order to partially close this gap: > > Keep action code on a client-side, sort of what StackStorm does. But IMO we > could think about automating it in a more elegant and transparent way. For > example, we could use decorators in python code that would associate a > function or a class with a certain workflow task. Then a workflow could call > this code back while its running using some mechanism (i.e. some special > action). In this case, however, we’d have to have a process handling > callback requests from Mistral on a client side. The alternative: using HTTP > Long Poll mechanism so that a client could claim available tasks itself. > We have BP [1] that describes the idea of using so-called action providers. > It assumes that we can register trustworthy action providers that could > dynamically provide new actions to Mistral. I personally like this idea and > to some extent it would solve this issue but it requires some additional > setup which works for cases like StackStorm but doesn’t work if we want to > use Mistral as is, as a hosted workflow service. > > > > Anyway, whatever solution we accept it will be a trade-off and depend on a > particular use case. > > > > Ad-hoc actions may also work for you if, for example, we create enough base > actions that they could be built upon. Say if most of your actions are HTTP > based then you can just create your own library (e.g. a workbook) of ad-hoc > actions that will be wrappers around std.http. > > > > Also look at what StackStorm does, it may also be helpful. > > > > Thanks > > > > [1] https://blueprints.launchpad.net/mistral/+spec/action-providers > > > __________________________________________________________________________ > 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 > -- Regards! ----------------------------------- Lingxian Kong __________________________________________________________________________ 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