Powershell and Salt

[shamuraix]

Would it be worthwhile to contribute alternatives for ansible and shell scripts, that leveraged other tools like Salt and Powershell. Might help get people started who already have investment in other tools or have mandates to use specific tooling. Would it be acceptable to add these directly here or would it be better to fork and rip/replace? Maybe have separate branches for different combos? I'm still new to best practices when it comes to Git so please excuse any newbie mistakes in my recommendations.

[tenthirtyam]

I'm willing to consider both for the project. Let me know what you would propose, the use case, and how it could be maintained and tested.

For example, having separate branches would cumbersome to maintain whereas, having the ability to toggle the provisioning options to/from Ansible to PowerShell would be a cleaner implementation.

For now, the project uses Ansible for Linux (as of v22.02) and PowerShell for Windows.

Ryan

[shamuraix]

Totally agree on the branches bit, just spit-balling. I'd prefer to have it as a toggle so users can decide when they initialize the environment.

Initially I think it would be worthwhile to add powershell alternatives to config.sh, build.sh, and set-envvars.sh. Then updated the README with relevant info on using them.

As for the CM tool I agree that Ansible is a solid user friendly choice for the recommended or default option. I recently started brushing up on SaltStack after the VMware acquisition so that would be a great contender as an alternative. I have some pretty solid builds leveraging salt-masterless that are almost as easy to run as our previous ansible setup with the exception that the ansible-plugin is the last supported CM plugin that's actively being developed in packer with all the others being pretty much abandoned. Its easy enough to work around it by using the shell provisioner to call other CM tools like Salt.

Testing can be done in much the same way as Ansible testing but I'd want to leverage the same framework your currently using to test the Ansible playbooks if at all possible. I'm open to contributing some initial tests as well.

Hopefully I've answered your questions adequately, let me know what you think.

[tenthirtyam]

I'd recommend starting off with sibling pwsh scripts for the existing .sh scripts.

It's been on my "backlog" for a long time but since the project focused only on testing with Ubuntu and macOS (what I use) it's not been a priority. In fact, I'd prefer moving over to pwsh exclusivley since it works on each OS. Completing the move of all Linux images to cloud-init >= 21.3 with the new VMware data source and local GHA runners are my next goal but pwsh could come first.

Configuring salt-masterless as a config management choice would be a welcomed addition to collaborate on. You can find me on the VMware {code{} Slack as @tenthirtyam for sync/async discussion.

Ryan

[tenthirtyam]

A couple of other things on the backlog also include:

1. Cloud-Init Coverage for Linux
2. Simplify and parameterize build.sh for easier maintenance
3. Add RHEL/RHEL derivatives for v9 when GA
4. Add Ubuntu 22.04 LTS when GA
5. Adding HCP Packer use case

[shamuraix]

Would love to help with those, I'll reach out on slack.

One thing I've been working on a bit is replacing the autounattend.xml method with cloudbase-init. Might be worth looking into for cloud-init style workflow for Windows with support for BSD coming.

https://github.com/cloudbase/cloudbase-init