Open Stack

Hello,

Ad ... The networking in OpenStack in general works in such a way so that connections from VM are allowed to almost anywhere. )
IMO it is defined by user what networks are accessible from VM – i.e., there can be several ‚public networks‘
Ad There is difference in direction who initiates connection. In case of murano agent --> rabbit MQ is connection initiated from VM to openstack service(rabbit). In case of std.ssh mistral action is direction opposite from openstack service (mistral) to ssh server on VM.)
And In Murano production deployment we use separate MQ instance so that VMs have no access to OpenStack MQ.

Yes and no ☺ In case of SSH the direction is obvious – from Mistral to VM.
But in case of MQ it is nearly the same, but both VM and Mistral are accessing the MQ – so the direction is Mistral to MQ, and VM to MQ. In this case it is important on what network the MQ is running – is MQ running on VM (managed by nova), or on O~S node? In both cases we have to solve how neutron network will be available to O~S node:

·         MQ is on VM (managed by nova)

o   VM with Murano agent has to be on the same network, or via router as MQ

o   Mistral (and of course Murano engine) has to be configured to have access to VM with MQ e.g., via floating IP, or manually configured namespaces ?

·         MQ is on O~S node

o   VM with Murano agent has to be configured to access ‚public network‘ with MQ

o   Mistral and (Murano engine) will have access to MQ (as they are running with all O~S nodes)

Gosha) In production environment - do you have ‚management network‘ on which MQ, VMs-with-Murano-agent, and Murano-engine, Mistral are running ?

Anyway I like more idea of using MQ for execution of actions (such as ssh) instead of direct ssh.

 Regards,
            Radek

From: Georgy Okrokvertskhov [mailto:gokrokvertskhov at mirantis.com]
Sent: Wednesday, May 06, 2015 6:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Murano] [Mistral] SSH workflow action

Connection direction here is important only in the frame of networking connectivity problem solving. The networking in OpenStack in general works in such a way so that connections from VM are allowed to almost anywhere. In Murano production deployment we use separate MQ instance so that VMs have no access to OpenStack MQ.
In the sense who initiates task execution it always a Murano service which publishes tasks (shell script + necessary files) in the MQ so that agent can pull them and execute.
Thanks
Gosha


On Wed, May 6, 2015 at 9:31 AM, Filip Blaha <filip.blaha at hp.com<mailto:filip.blaha at hp.com>> wrote:
Hello

one more note on that. There is difference in direction who initiates connection. In case of murano agent --> rabbit MQ is connection initiated from VM to openstack service(rabbit). In case of std.ssh mistral action is direction opposite from openstack service (mistral) to ssh server on VM.

Filip


On 05/06/2015 06:00 PM, Pospisil, Radek wrote:
Hello,

I think that the generic question is - can be O~S services also accessible on Neutron networks, so VM (created by Nova) can access it? We (I and Filip) were discussing this today and we were not make a final decision.
Another example is Murano agent running on VMs - it connects to RabbitMQ which is also accessed by Murano engine....

   Regards,

        Radek

-----Original Message-----
From: Blaha, Filip
Sent: Wednesday, May 06, 2015 5:43 PM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action

Hello

We are considering implementing  actions on services of a murano environment via mistral workflows. We are considering whether mistral std.ssh action could be used to run some command on an instance. Example of such action in murano could be restart action on Mysql DB service.
Mistral workflow would ssh to that instance running Mysql and run "service mysql restart". From my point of view trying to use SSH to access instances from mistral workflow is not good idea but I would like to confirm it.

The biggest problem I see there is openstack networking. Mistral service running on some openstack node would not be able to access instance via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from namespace of its gateway router e.g. "ip netns exec qrouter-... ssh cirros at 10.0.0.5<mailto:cirros at 10.0.0.5>" but I think it is not good to rely on implementation detail of  neutron and use it. In multinode openstack deployment it could be even more complicated.

In other words I am asking whether we can use std.ssh mistral action to access instances via ssh on theirs fixed IPs? I think no but I would like to confirm it.

Thanks
Filip

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com<http://www.mirantis.com/>
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150507/8daca5b8/attachment.html>