On Tuesday, October 17, 2017 at 7:59:16 AM UTC-5, jcbollinger wrote: > > Nothing has changed with `ensure_resource()`. The problem is not its > implementation details, but rather the nature of the usage modes the > function is *designed* to support. The whole idea of it is flawed. >
Funny story: I have recently been working with an "approved" Forge module, which will go unnamed. It has a long history, and overall is of high quality. But it happens to use ensure_resource(), and sure enough, that bit me in the ass: it is the cause of a module bug that crops up under relatively unusual circumstances. Then when I tried to fix the bug, ensure_resource() did it again. The failure mode isn't even among those I usually harp on. Maybe the function's behavior has changed over time, or maybe I never knew this about it, but in Stdlib 4, the function only protects against declaration of *identical* resources -- it will happily generate a resource with the same title as another that has already been declared, as long as there is a difference between their declared parameters. This of course elicits a duplicate resource declaration error from Puppet (and this is intentional: function's docs disclose it). And here's the kicker: after my attempted bugfix, the duplicate declarations in fact *are* identical, at least as expressed to ensure_resource(). They are rendered non-identical externally by application of a resource override. Apparently, the override is applied either together with application of the first ensure_resource() call in some way that messes up the resource comparison in the second, or between the effects of the first call and the effects of the second call. Maybe that's a bug. To be sure, I would rather have the function fail loudly than break quietly, but I would even more have liked to have a module that doesn't depend on ensure_resource() in the first place. John "ensure_resource() is evil" -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/46001944-4feb-4721-bf6c-b2a1b9daa9b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
