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 <john.bollin...@stjude.org>: > > > > 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 puppet-users+unsubscr...@googlegroups.com > <mailto:puppet-users+unsubscr...@googlegroups.com>. > 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 puppet-users+unsubscr...@googlegroups.com. 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.
