On Monday, March 31, 2014 1:08:25 PM UTC-5, Dan Bode wrote: > > > That being said, there are two reasons it may be problematic. > > 1. Behavior depends on parse order - this is probably the best reason not > to use it. >
And that is indeed an excellent reason not to use it. > The behavior of how it will fail depends on the order in which code is > parsed in Puppet. That is why this method (as well as defined(), and > resource collection overrides) should only be used by users who understand > this behavior, it's limitations, and how to debug it when they run into > issues. It's usage and the fact that it depends on the order in which your > code is parsed makes it problematic to have in modules that are intended to > be shared. > So ensure_resource() appears to be a solution to module compatibility issues, and sometimes is purported to be such, yet in practice it is "problematic" to use it for that purpose. Let me expand a bit on "problematic": - Ensure_resource() is only reliable for avoiding duplicate declaration of a given resource if every declaration of that resource anywhere in the manifest set is via ensure_resource(). It clashes with ordinary resource declarations and also with declarations via create_resources(). - The details of a resource declared via ensure_resource() are stable and predictable only if *all* declarations of that resource (via ensure_resource() and/or any other means) are consistent. - When working as designed, ensure_resource() actively suppresses any diagnostic information Puppet might otherwise emit regarding the existence of a real or potential compatibility issue. Now consider: is it wise to duplicate resource details at several places throughout a manifest set, and to undertake the maintenance burden of keeping them all synchronized, especially when you cannot rely on any signal other than possible (but not certain) misconfiguration of your production systems should you fail to meet your maintenance requirements? Do you really want to risk sudden failure of a Puppet-managed system triggered by modification of the manifests for something completely unrelated? Ensure_resource() is intended to ease construction and maintenance of complex manifest sets, especially those involving many modules, but using it safely is actually more work than avoiding it. Moreover, if you use ensure_resource() in a shared module, then you saddle all users of the module with those maintenance issues -- usually unbeknownst to them. And here's the icing on the cake: the ensure_resource() function creates more work for me simply by existing. If I want to avoid all of the maintenance issues it presents then I need to audit every third-party module I use. Without it I may still need to modify third-party modules, but Puppet will *tell me* when I need to do so. If nothing else does so, then that puts ensure_resource() over the top into the "evil" category. In case it was not clear, this is not about unintended uses of ensure_resource(); it is about the function's core use case. The whole concept of the function is wrongheaded. If you don't like "evil" then choose another adjective that suits you better, but whatever you do, DO NOT USE ensure_resource(). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/433cf9ec-b3e6-42c9-aaac-a35bb5025576%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
