Hi John, thanks for your support! I see your point, especially with the different use of notify.
It’s disapointing to hear one should still keep away from ensure_packages, as it greatly helps me to install packages only when needed. This goes mostly for apache modules and php extensions in my case. I will try to prepare a simple test which I can share. Nevertheless the question remains why the code is working in my dev environment. Both environments are the same as much as you can get. Regards Jochen > Am 31.01.2019 um 15:28 schrieb jcbollinger <[email protected]>: > > > > On Thursday, January 31, 2019 at 8:00:05 AM UTC-6, jcbollinger wrote: > > As long as I'm standing on this soapbox, though, I'd like to remark that > ensure_packages() is a jerry-rig, not an actual solution to any Puppet > problem. It and its brethren, ensure_package(), ensure_resources(), and > ensure_resource() should be avoided. > > Oops: there is no ensure_package(). But the point remains. > > As for the code you've presented, it indeed does reveal a problem, which is > also illustrative of my soapbox position. One of the larger issues here > revolves around what to do when there are two or more declarations of a > resource that specify different parameters. The two parameter lists cannot > both be satisfied (generally speaking), so which do we choose? In fact, the > functions in question make the safe choice: none of the above. Per the docs > for ensure_resource() > <https://forge.puppet.com/puppetlabs/stdlib#ensure_resource>: > > If the resource already exists, but does not match the specified parameters, > this function attempts to recreate the resource, leading to a duplicate > resource definition error. > > In your case, one declaration of Package[libapache2-mod-php7.3] has a notify > parameter and the other does not. > > There are several ways you might refactor this to solve the specific problem, > but I would suggest one of these: > moving management of mod_php out of the apache profile > My first inclination would be to put it in its own profile, or at least in > its own class, but > you could also leave it as a responsibility of the Wordpress profile > moving management of mod_php out of the Wordpress profile > Again, you could put it in its own class or profile, but > you could also let the Apache profile continue to manage it, possibly under > control of a class parameter > Of course, you could also just ensure that the specified parameters are > identical in both places, but if you're relying on ensure_packages / > _resources / _resource a lot, then you will likely find that that becomes > tedious and error-prone. > > > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/b67eecc5-1145-4eff-8d6b-fbf8808236e3%40googlegroups.com > > <https://groups.google.com/d/msgid/puppet-users/b67eecc5-1145-4eff-8d6b-fbf8808236e3%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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/00300BBF-1BD4-43F4-A345-5D9707F53926%40gmail.com. For more options, visit https://groups.google.com/d/optout.
