-
Notifications
You must be signed in to change notification settings - Fork 264
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
Updated installing salt with its bootstrap script, and enabled specifying the CM_OPTIONS for all the configuration management tools #201
Conversation
Presently these two cases against the eval-win7x64-enterprise.json template.
|
Lol. This PR is blocked by saltstack/salt-bootstrap#1406. Go figure. Depending on how they respond (I'm not crossing my fingers or anything), this might result in bundling salt-bootstrap.ps1 in this project. |
This PR is also blocked by saltstack/salt-bootstrap#1394. SaltStack's such a joke sometimes... |
As saltstack has a tendency to drop the ball on their issues and PRs, I'm right now testing with letting the user specify the branch that If this works, i'll update this PR with the changes and the documentation with the revision that's hardcoded prior to merge. |
Going to split the CM_OPTIONS parameter from this PR so that the other config management tools can benefit from this. It seems that with the recent merge of PR #200, exposing an external option can be used for things like licensing, branches, etc. |
The split of the CM_OPTIONS parameter is done by PR #203, this PR will be rebased onto that one. |
Official bootstrap script written in Powershell is used. `CM_OPTIONS` are passed as arguments (see `README.md`). PS: old way of installing Salt was limited and no longer works.
…which retains usability of the CM_VERSION variable when installing salt.
…nfiguration management tools, and updated README.md to reference it.
…bootstrap in order to fix issue saltstack/salt-bootstrap#1406.
…ool.bat when using a platform not supported by salt-bootstrap.
…versions are properly trimmed.
…script/cmtool.bat now fetches using non-ssl when falling back to the saltrepository method.
(force pushed due to rebase on top of master) |
Okay. So here's what was done.
|
I'm re-testing the following platforms after the force-push.
|
…added checks for more versions when determining whether to use saltbootstrap or saltrepository.
Added some futureproofing by including some more checks for platform versions as per https://docs.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version |
Okay, other than wget.exe issues and other template-specific things (that eventually need fixing). All relevant code checks out. Merging... |
Goddammit, that was supposed to be a merge-commit. |
This PR is based on PR #182, and supersedes it. The original intent of the PR is to fix the installation of the SaltStack configuration management tool. Originally we were hardcoding the path to the SaltStack minion url, dowloading, and then installing it. Since then SaltStack has introduced a bootstrap script (https://github.com/saltstack/salt-bootstrap) to install a minion which is used by this PR to automatically determine the url of the correct package to install.
The original PR introduced a new option,
CM_OPTIONS
, that allows the user to customize the options for SaltStack. It was discovered that inscript/cmtool.bat
, all of the configuration tools use their own variable for passing options to their installer (i.e. PUPPET_OPTIONS, CHEF_OPTIONS, etc).Despite their available, they have each been left undefined. As it seems that passing options to each of these was intended, this PR extends the
CM_OPTIONS
capability to each of the configuration management tools. This allows the user to explicitly control the options if they so desire.It should also be mentioned that all of our templates have been modified to support the
CM_OPTIONS
environment variable. (This is why this PR touches so many files).