Hi all, I would appreciate your help clarifying my thinking around the following problem.
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 possible. 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, James -- 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
