Re: [Puppet Users] Re: ensure_resource should be the default behaviour

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

On Thu, Feb 16, 2017 at 11:20 AM jcbollinger 
wrote:

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

[Puppet Users] Re: ensure_resource should be the default behaviour

[jcbollinger]

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

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