On Fri, Oct 14, 2011 at 14:18, Adrien Thebo <[email protected]> wrote: > One of the things I've noticed is that puppet doesn't handle indirect > usage or reference of resources. For instance, there's the often cited > case of wanting to upgrade vulnerable packages, but only if they're > present on the system.
This smacks of a fundamental modelling problem; you should specify that they are either `latest` or `absent`, I think. > It would be nice to be able to pull in more > system information like packages installed, but not have to manage > them. However, I've got a (possibly bizarre) solution to this. In > theory, we could have facter use puppet resource or self.instances on > providers to get the current system state and then inject that back > into puppet as variables. That would be the usual recommendation. Well, at least, we usually recommend that if you really want to make this mistake you should do that by > This would depend on namespaced and > structured variables being present on facter, but that should be > coming down the pipe in the near future. I am surprised you have already solved the significant problems getting those to work smoothing in Puppet. I would have expected substantially more changes to be required, on a scale that would call for a 2.8 (or whatever) release before they could even be considered. > Would this be a good approach > to solve the given problem? No. It isn't even a good problem, which doesn't help, but this is a worse solution. If you really want to do ad-hoc management like this then MCollective is the tool you are after: it is, by design, focused on using the network as the source of truth. In MCollective it is trivial to express the logic "find me all machines with this package, and on those ensure it is of at least version X". This is the design purpose of the tool. In Puppet it is both cumbersome and inefficient to do this. Puppet is designed to specify the state of a system, not to interrogate it, and to enact your static orders, not to evaluate a complex set of conditions to determine the best course of action. You will constantly be working against the grain of the tool trying to do this. We have some intent to better capture the information that we discover from both tools, to more easily answer questions like "which machines are vulnerable", but it is highly unlikely that using Puppet to achieve this result will *ever* be a good thing. Other tools in our ecosystem, sure, but not the core of Puppet itself. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
