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:gokrokvertsk...@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.bl...@hp.com<mailto:filip.bl...@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@lists.openstack.org<mailto:openstack-dev@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@10.0.0.5<mailto:cirros@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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
__________________________________________________________________________
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
