Orchestration outside tenant network for multi-tenancy

[trihoangvo]

Issue Type

• [ ] Bug report
• [ ] Documentation issue report
• [X] Improvement request

Description

In the current design, Yorc has to SSH to a VM to setup / update the software component on the VM via its private IP Address. Therefore, it only works when Yorc is in the same tenant network as the VM.

Limitations

• As a result, we have to create one Yorc (2 CPUs, 2 GB Ram) for each tenant network --> not efficient.
• From the security perspective, we cannot allow 1 single machine (i.e., Yorc) to SSH to all VMs in the system.

Expected behavior

• An agent running on the VM actively queries and execute tasks from Yorc (e.g., via messaging queue).
• The VM does not need to have a public IP address.

Priority

Medium (highly recommended)

[loicalbertin]

Hi @trihoangvo,

Thanks for your feedback. Indeed, currently Yorc relies on Ansible to execute scripts and playbooks on target machines and Ansible has an agentless provisioning model. This model matches most of the use-cases we have encountered so far and we do not plan to work on a different model in the near future.

But there is some good news:

1. we have in backlog to support provisioning through an ssh-bastion (#128)
2. as a workaround we can provision using public IPs for GCP, AWS, OpenStack (See provisioning_over_fip_allowed configuration param for OS)
3. Ansible is the builtin provisionner but you can use plugins to add new provisionners with a completely different model like chef for example which use agent-based provisioning. You can even write your own using your own messaging system. (Plugins documentation)

Hope this helps!

Finally we warmly welcome external contributions so you are interested in contributed a new agent-based provisionner we could discuss on integrating it in Yorc as builtin.

[trihoangvo]

Hi Albertin,

thank you for your reply.

1. Then a customer must create an additional VM (i.e., bastion host) and has to pay for the VM.
2. Then each VM requires a public ip...
3. In OpenStack Heat and Cloudify, an agent is a secured way to retrieve a script (e.g., Ansible) via private network and apply it.

I think multi-tenancy is an important feature...

[loicalbertin]

@trihoangvo, I totally agree, multi-tenancy is an important feature, and it can be addressed in several ways as described above.

Life is matter of trade-off, agent-based provisioning come with drawbacks, just like agent-less provisioning do. Ideally, choice should be let to the final project/user according to circumstances.

But again, right now, we have so much others exciting features to implement that supporting another provisioning model is not our near future plans. And again we are open to contributions on this :smiley:.