On Wednesday, February 15, 2017 at 11:08:09 AM UTC-6, Poil wrote: > > Hi, > > After some years of writing puppet modules, I think the ensure_resource > behaviour (from stdlib) should be the default behaviour for all resources. > > This will simplify the code, and made Puppet more accessible for > beginners. > > Ref. https://forge.puppet.com/puppetlabs/stdlib/readme#ensure_resource > Takes a resource type, title, and a hash of attributes that describe the > resource(s). > 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. > > So I think I'm not the first to ask for this, so why not ? >
You're right, you're not the first to suggest this. You will find multiple discussions on this topic in the archives of this group and of the developers group. The most recent one I recall was in the context of a discussion of changes to the syntax and semantics for resource declarations for (then-future) Puppet 4. Some of the ideas from that discussion were in fact implemented, but not the ones around reducing the duplicate declaration problem. Perhaps the existence of ensure_resource() was considered to adequately address that aspect already. Of course, this is primarily a module compatibility issue, for within a single code base, it is entirely feasible to solve the problem via one of the means Puppet recommends <https://docs.puppet.com/puppet/4.9/lang_resources.html#uniqueness>. In a more general context, some of the same ideas still apply -- in particular, it makes some sense to approach the problem by stipulating that there shouldn't *be* a problem: instead, there should be at most one class (and therefore one module) in any manifest set responsible for any given resource, and the only way that resource it should be managed is via that class. Other modules would depend on the designated module / class instead of managing the resource directly. But that solves the problem by kicking it up a level, making it one of module *set* design and curation. In the end, I think the biggest problem with the suggestion of changing resource declaration semantics to match the semantics of ensure_resource() is that despite being a substantial semantic shift, it would not completely solve the problem. It would handle the case of multiple *identical* resource declarations but not cases of multiple *compatible* declarations. This latter is quite a hard problem, because it is not clear *a priori* what makes non-identical declarations compatible. I once had some ideas on this topic that I still think are pretty good, though fully implementing and using them would be much more disruptive at this point than when I first suggested them. Nevertheless, you might find this discussion <https://groups.google.com/forum/#!msg/puppet-users/Fvl0aOe4RPE/kGFVbbIY3TYJ> of interest. Felix Frank later implemented some of those ideas <https://github.com/ffrank/puppet-constraints>. I'm game to have this discussion again in the context of present-day Puppet and its ecosystem, but inasmuch as Puppet, Inc. has had multiple suggestions and ample opportunity to make the changes you seem to want, and has not made them, I think it's a lost cause. 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/943c7176-af10-4436-bec3-949cbdd0e48e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
