[openstack-dev] [mistral] How to call 3rd-party tools(such as Ansible) in Mistral

Lingxian Kong anlin.kong at gmail.com
Tue Oct 20 10:01:02 UTC 2015


Hi, Minghao,

The answer is yes, if you want to use Ansible playbook in you
customized 'ansible actions', you need put the playbooks under a place
that your code has access to.

BTW, you can send personal email to me in Chinese, in case you want to
solve your problems quickly :-)

On Tue, Oct 20, 2015 at 4:58 PM, WANG, Ming Hao (Tony T)
<tony.a.wang at 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:rakhmerov at 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.wang at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
-----------------------------------
Lingxian Kong



More information about the OpenStack-dev mailing list