I would appreciate your help clarifying my thinking around the following
Let's say I have a third-party (one that I didn't write) package x which
depends on a package y.
Package x is installed somewhere and is working fine against package y (as
in package x has been QA'ed and verified to work against package y).
Now, let's imagine I need to spin up another server to meet some load but
when I do so I find that package y has had a security fix that has caused a
problem in package x.
This is probably a bit of contrived case but could at least happen in
theory. Normally, I'd want to test the fix out before I put it live but in
this case because I had to spin a
server to meet some load this wasn't possible and as such my package
versions has skewed between my old and new servers.
The obvious solution to this would be to manage package versions explicitly
but is likely to become cumbersome quite quickly especially since I may not
even be managing
package y in my manifests explicitly.
Another solution might be to have my own package repository containing just
the packages I have tested against and only install from there but that
means another bit of
infrastructure to look after and manage, which I'd like to avoid if at all
One idea I had was to maybe have a script that dumps out package versions
and use that to either seed hiera or create package resources automatically
but I'm not sure if this
is a good idea or not.
What sort of solutions are people using to get round this?
Thanks for your help,
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zLYnmQ-X5D4J.
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to email@example.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.