Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST]Saltstack integration in vra/aria automation #63344

Open
lehbot opened this issue Dec 20, 2022 · 12 comments
Open

[FEATURE REQUEST]Saltstack integration in vra/aria automation #63344

lehbot opened this issue Dec 20, 2022 · 12 comments
Labels
Feature new functionality including changes to functionality and code refactors, etc. needs-triage

Comments

@lehbot
Copy link

lehbot commented Dec 20, 2022

Is your feature request related to a problem? Please describe.

Vmware acquired saltstack and "integrated" this product also into vra/aria automation.
Sadly the integration was mainly gui related.
Like most enterprise companies we have a segmentation between our customers and roles of several servers.
So this is going to be a problem when rolling out the minion.
Normally the required ports are open from client to server and the port is 4506/tcp mainly.
This would be no problem.
The problem is, that when you want to use the cloud template/blueprint when deploying a server and want to use the saltstack property to apply a state initially, the process wants to deploy the agent.
For that process the saltstack master needs to contact linux servers via ssh with a user and windows server via winrm on port 445/tcp. On windows additional configuration needs to be done. Winrm has to be configured on port 445/tcp.
These are two problems:

  1. We do not want to open the firewall temporarily from the master to the client for SSH or 445/tcp. We have a separate department that checks and opens every firewall port. So this is not an automatic process and also is not supposed to be. Also this is normal in an enterprise environment.
  2. We do not want to configure WinRM on port 445, although we know that we can reset that configuration afterwards in fear of a security hole or breaking SMB Connections.

Describe the solution you'd like
We want a process that rolls out the agent, in dependancy of the used environment. We have the full stack from vmware, so this would be possible. Also we want to have an initial state file applied when the agent gets deployed, like intended now, when using the saltstack property in the cloud template/blueprint.
Also we want to have the saltstack resource to appear in vra/aria automation like it is intended at the moment.
One possible process desing would be:

  1. vra deploys a blueprint.
  2. it mounts a source with the agent binaries (e.g. an iso on vsphere)
  3. via vmware tools in guest acion it installs the agent with parameters fitting the environment (saltstack master address/uri)
  4. vra then detects that the deployed server makes a request and is in pending state and applies it.
  5. The defined blueprint state will be applied
  6. Finish

Describe alternatives you've considered
Workarounds that were considered are like treating the saltstack master like it would be not integrated into vra were considered.
Also Ansible.

Please Note
If this feature request would be considered a substantial change or addition, this should go through a SEP process here https://github.com/saltstack/salt-enhancement-proposals, instead of a feature request.

@lehbot lehbot added Feature new functionality including changes to functionality and code refactors, etc. needs-triage labels Dec 20, 2022
@welcome
Copy link

welcome bot commented Dec 20, 2022

Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
Please be sure to review our Code of Conduct. Also, check out some of our community resources including:

There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar.
If you have additional questions, email us at saltproject@vmware.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!

@OrangeDog
Copy link
Contributor

You should make this request via your Enterprise support.

The Salt Open community has no control over how VMWare integrates its products.

@lehbot
Copy link
Author

lehbot commented Dec 20, 2022

Hey,
ok, can i say that you said this to me? Because their idea was that i open up a feature request here....
HAHA i cant stand this behavior. This is so funny by vmware.

@OrangeDog
Copy link
Contributor

OrangeDog commented Dec 20, 2022

It seems to be a feature request for VRA not for Salt, so I'm not sure why they'd want that.

I have no idea how VRA works, but can't you create new VMs that will install salt-minion themselves, or already have it installed? Then all you need is automated key acceptance, which is available e.g. by trusting a custom grain on the minion, or you can also automate it with a reactor I think.

There also might be an option in salt-cloud that doesn't use SSH?

@lehbot
Copy link
Author

lehbot commented Dec 20, 2022

Yes, but this goes beyond the integration into vra itself. This would be like having salt in any environment and we would to use the benefits of the integration between vra and saltstack. This is what i would expect when a vendor says "look, we have integrated product x into product y".
Developing a workflow on ourselves is also more like a workaround, which would be possible on our own, but then we could also consider any other product like Ansible or puppet.

@UtahDave
Copy link
Contributor

There is now a Salt resource in vRA that you can use in your blueprint, @lehbot

Have you tried it yet? I think we can close this issue now.

@lehbot
Copy link
Author

lehbot commented Jul 19, 2023

There is now a Salt resource in vRA that you can use in your blueprint, @lehbot

Have you tried it yet? I think we can close this issue now.

Hi, since when is this feature implemented?
How is the deployment of the agent done specifically in vra using vsphere/vcenter?

@UtahDave
Copy link
Contributor

It's been available for several months. I don't know which release was first.

When you're creating your blueprint you can add a Salt resource and set various values like grains and sls files to apply to the minion.

@UtahDave
Copy link
Contributor

@lehbot
Copy link
Author

lehbot commented Jul 20, 2023

@lehbot I think this doc should help you get started with it.

https://docs.vmware.com/en/vRealize-Automation/8.11/Using-and-Managing-Cloud-Assembly/GUID-7A6A9F67-0B47-4789-A748-D23B71C15D39.html

The thing is how VMware integrated Saltstack into vra. The integration is the GUI only. You have temporarily open ports so the agent gets deployed. That is not a good idea because in enterprise environments you have a firewall everywhere, which leads to my problems in my initial post:

These are two problems:

We do not want to open the firewall temporarily from the master to the client for SSH or 445/tcp. We have a separate department that checks and opens every firewall port. So this is not an automatic process and also is not supposed to be. Also this is normal in an enterprise environment.
We do not want to configure WinRM on port 445, although we know that we can reset that configuration afterwards in fear of a security hole or breaking SMB Connections.

@UtahDave
Copy link
Contributor

The salt-minion is part of vmtools now, as well.

@lehbot
Copy link
Author

lehbot commented Jul 20, 2023

The salt-minion is part of vmtools now, as well.

Interesting. Do you have an article about that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature new functionality including changes to functionality and code refactors, etc. needs-triage
Projects
None yet
Development

No branches or pull requests

3 participants