ansible-role-for-splunk
ansible-role-for-splunk copied to clipboard
splunk
fix(install_utilities): restore ability to set custom `linux_packages` list
https://github.com/splunk/ansible-role-for-splunk/pull/168 inadvertently removed the ability for users to customize the linux_packages list.
Due to ansible variable precedence and include_vars having such a high priority we need to use unique vars and use default() if the user doesn't customize the variable.
The packages var has been annoying me for some time. IMO, the default packages should be acl and sysstat only, Those are required for setting permissions, and for the *NIX TA to work, and there should be no additional default packages.
What I would like to know is if you add a package in linux_packages_custom that is not available in that distro, what will happen then?
It will fail, but at that point I think it's on the user who set the customization to use a non available package to remove it from their custom list and re-run.
Nothing we can do to prevent it.
@zyphermonkey
It will fail, but at that point I think it's on the user who set the customization to use a non available package to remove it from their custom list and re-run.
I agree 100% that this needs to be customizable, and we need a better way to do this based on platform. In most cases, the Full installs are usually on the same platform, so having a custom list will work fine. but UFs' are widely diverse, and the whole thing will fall apart when trying to deploy or upgrade a environment with 1000s of UFs.
Or maybe we assume that people are not using this role to install additional packages on UFs', but are rather using a separate role, or something else to do a base configuration on their hosts. Base configuration is not the purpose of this role. In that case, we should remove it altogether from here, and only leave acl and add systat to prereqs.yml. We can leave the linux_packages option available like you said if someone does want to use this role for installing packages at their own risk of breaking it.
In most cases, the Full installs are usually on the same platform
I find it hard to imagine a scenario where one would want to support an environment that wasn't the same platform. So I think we are safe in making the assumption that all installs are on the same platform.
If we make that assumption then it might be possible to just go back to a single linux_packages under defaults/main.yml with an extremely small, but common list of packages like the ones you suggested.
Or maybe we assume that people are not using this role to install additional packages on UFs,
I currently do not use this role to manage any UFs as we already had a custom role built long before this to manage the install, config, and upgrade of our UFs. We try to keep our presence on all our servers small so we don't install anything along side the UF (requirements for TA_nix are handled by our core baseline).
With that said we should be sensitive to users who are using this to install/manage a fleet of UFs.