Enhancement: Add ability to set install packages to "on hold"

[frankhetterich]

Please add the ability to mark the ELK install packages as "on hold" in the packet manager during the installation process.

It would be very useful to have the packages on hold (e.g. apt-mark hold elasticsearch) so you don´t have to take care about the packages when installing updates on the host system. At the moment it could happen that you´re accidentally updating a ELK component during a "normal" update install on the host system.

[martialblog]

I think this is out-out-scope for a collection and should be implemented in the specific plays a users writes.

For example, there are the ansible.builtin.dpkg_selections and the yum_versionlock modules to achieve this. Otherwise each Ansible collection would have to implement this which would be extremely redundant.

@widhalmt @DanOPT what do you think?

[widhalmt]

Hm... I'm a bit torn between offering it with the collection or not. As possible compromise would be to use the modules @martialblog mentioned and lock the packages from the collection. Maybe only if you tell the collection to install a specific version.

I know of some projects who have a very valid reason to install a very specific version and they can't risk a change. How about enhancing this with locking the packages? So if you set up new hosts they also get the same version and it won't change.

If you need an update you need to deal with the lock yourself. We could give hints in the README.md but I don't see a point in automatically releasing the lock. That could be something for an upcoming "update" feature which we don't have in the moment.

What do you think? (Calling @afeefghannam89 and @dnssmr in the circle, too)

[afeefghannam89]

We can supply the version lock as you mentioned @widhalmt and if the user wants this with a boolean variable, also when he installed the latest version. It is more system administration workflow than what this collection should do, but it will not impact the collection or harm its functionality.

[widhalmt]

I agree that this might be a bit overboarding for the collection. On the other hand we already decided we'll change limits and install dependencies, so I'm basically ok with getting some sysadmin stuff into the collection. That's one of the questions I never got a good and definitive answer when trying to figure out where the red line is.

[martialblog]

I would argue that changing limits and installing dependencies falls into scope, since it is directly related to the installation of the tools in the collection. Pinning packages to me would be out of scope since it is indirectly related, similar to managing disks/quotas on the node or system hardening. This is why would argue for the separation of concerns principle here.