ensure_resource should be the default behaviour

[Benjamin DUPUIS]

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 ?

Best regards

[jcbollinger]

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.  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 of interest.  Felix Frank later implemented some of those ideas.

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

[Rob Nelson]

To elaborate on the problem set it would solve:

If you were managing the same user in two locations and all you did was set ensure to present, by matching the create_resources behavior in default resource declaration, you'd resolve the duplicate declaration issue. Fine and dandy.

If you were managing the group membership of the user and the other reference wasn't, now you have a duplicate declaration because create_resources only matches two resource declarations with the same parameter set, as John mentioned. No good, but still expected so not really a problem.

We've now defined where it works and where it doesn't. Good, right?

One of the resource declarations generates the parameters dynamically, maybe using the new * meta-parameter. The data fed to it over time changes. Or a module is updated and it changes the parameter list in the new version. Or two. Does generate different dynamic data. Working code is now not working and generating duplicate declarations.

This seems likely to happen with your knowledge, but it's really easy for the two resource declarations to be in two different modules and a third one assists with generating the dynamic data, for instance. The only way to fix this is to create some sort of protection in one or both modules, such as a $manage_resource feature flag to disable managing the resource in at least one location. 

The combination of change in behavior for resource declaration and the use of dynamic data doesn't actually change the need for defensive coding by the developers, but it does potentially delay discoverability of such conflicts from introduction of the code to a later time, which is likely to be a more inconvenient time for the users.

That seems like a dubious trade off to me. 

--
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...@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.

--

Rob Nelson