Open Stack

Hi Tony,

Technically your solution is possible. Murano agent can be installed
manually. All queue names are in agent's config file. Murano can talk to
that manually installed agent and put files to that server.

However I strongly advice not to do that. First of all it is not secure.
Murano agent was designed as a remote execution mechanism rather than a
tool to transfer files. Also it was design to be installed on VM
rather that on a shared server. Currently there is no authentication for
agents. Although it is not truly secure it still provides significant level
of security because to make use of the agent you need to know its queue name
which is a long random string that only murano engine and agent know and
AMQP doesn't provide an API to query list of queue names. But if you
install agent manually there will be a single queue. And all applications
that
need to access that agent will also need to know queue name. Thus it can be
easily be compromised and attackers will gain ability to execute arbitrary
code on the nova server.

It is also doesn't seem like a right solution. There should not be such
specific requirements like this to perform such trivial thing. Especially
if it involves using tool that was design for something else.

So what is the right solution?

I can see 2 possible ways to address this issue:

1. Improve Mistral API to support file attachments to its workbooks (if it
doesn't support it yet). Improve murano-mistral integration to support this
feature.
2. Implement integration of Murano with object storage. Thus it will be
possible from Murano workflow to upload file and provide Mistral with a URI
to it.

Solution #2 seem to be better. At least because it opens new possibilities
for all applications and not just those that use Mistral.

There is also a workaround that I can think of: make Murano application
create temporary VM with FTP server or something like that, put file into
it and give Mistral a URI it could use to access the file.

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

<slagun at mirantis.com>

On Wed, Nov 18, 2015 at 1:06 PM, WANG, Ming Hao (Tony T) <
tony.a.wang at alcatel-lucent.com> wrote:

> Dear Alexander and Murano developers and testers,
>
>
>
> Any suggestion for this? J
>
>
>
> Thanks,
>
> Tony
>
>
>
> *From:* WANG, Ming Hao (Tony T)
> *Sent:* Tuesday, November 17, 2015 6:12 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* RE: [openstack-dev] [murano]How to use Murano to transmit
> files to Mistral and execute scripts on Mistral
>
>
>
> Alexander,
>
>
>
> Thanks for your response.
>
> During the workflow running stage, it may need to access some other
> artifacts.
>
> In my case, I use Mistral workflow to call Ansible playbook, and I need
> Murano to put Ansible playbook into right place on Mistral server so that
> Mistral workflow can find it.
>
>
>
> Thanks,
>
> Tony
>
>
>
> *From:* Alexander Tivelkov [mailto:ativelkov at mirantis.com
> <ativelkov at mirantis.com>]
> *Sent:* Tuesday, November 17, 2015 4:19 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [murano]How to use Murano to transmit
> files to Mistral and execute scripts on Mistral
>
>
>
> Hi Tony,
>
>
>
> Probably I am missing something, but why do you need Murano Agent to
> interact with Mistral? You can call Mistral APIs right from MuranoPL code
> being executed by Murano Engine. Murano's core library contains the io.murano.system.MistralClient
> class ([1]) which may be used to upload and run mistral workflows.
>
>
>
> Please let me know if you need more details on this
>
>
>
> [1]
> https://github.com/openstack/murano/blob/master/murano/engine/system/mistralclient.py
>
>
>
> On Tue, Nov 17, 2015 at 5:07 AM WANG, Ming Hao (Tony T) <
> tony.a.wang at alcatel-lucent.com> wrote:
>
> Dear Murano developers and testers,
>
>
>
> I want to put some files that Mistral workflow needs into Murano package,
> and hope Murano can transmit them to Mistral before it calls Mistral
> workflow.
>
> The flow should be as following:
>
> 1.                   User uploads one Murano package which includes both
> Murano artifacts and Mistral artifacts to Murano;
>
> 2.                   Murano transmits the Mistral artifacts to Mistral,
> and Mistral does its work.
>
>
>
> After study, I thought muranoagent may be helpful and plan to install a
> muranoagent on the Mistral server since it can put files into nova server,
> and can run scripts on the nova server.
>
> After further study, I found muranoagent solution may be not feasible:
>
> 1.                   muranoagent and murano-engine(dsl) uses rabbitMQ to
> communicate.
>
> 2.                   When an Agent object is created in DSL,
> murano-engine creates a unique message queue to communicate with the
> muranoagent in nova instance:
>
> The queue name consists of current murano environment id, and the nova
> instance murano object id.
>
> 3.                   During murano creates the nova instance, it passes
> this unique queue name via nova user_data to muranoagent on guest.
>
> In this way, muranoagents on different guests can communicate with
> murano-engine separately.
>
> This doesn’t suit the muranoagent + Mistral server solution.
>
> We only want to install one muranoagent in Mistral server, and it should
> only listen on one message queue.
>
> We can’t create  new muranoagent for each murano environment.
>
> To achieve this, one solution that I can think is to modify murano code to
> implement a new MistralAgent to listen on a pre-defined message queue.
>
>
>
> Could you please share your ideas about this?
>
> If you have other solution, please also help to share it.  JJ
>
>
>
> Thanks in advance,
>
> Tony
>
>
>
> __________________________________________________________________________
> 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,
>
> Alexander Tivelkov
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151129/8c32400b/attachment.html>