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

fix(install_utilities): restore ability to set custom linux_packages list #169

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

zyphermonkey
Copy link
Contributor

#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.

@zyphermonkey zyphermonkey changed the title fix(install_utilities): restore ability to set custom linux_package list fix(install_utilities): restore ability to set custom linux_packages list Jan 28, 2023
@jewnix
Copy link
Collaborator

jewnix commented Feb 2, 2023

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?

@zyphermonkey
Copy link
Contributor Author

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.

@jewnix
Copy link
Collaborator

jewnix commented Feb 3, 2023

@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.

@zyphermonkey
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants