On Wednesday, March 21, 2018 at 8:46:02 AM UTC-5, jcbollinger wrote:
>
>
>
> On Wednesday, March 21, 2018 at 4:03:28 AM UTC-5, Martin Alfke wrote:
>>
>> I prefer the each lambda over ensure_resource and create_resource.
>> my 5pc.
>>
>
> In this particular case, the ensure_resource() call is
On Wednesday, March 21, 2018 at 4:03:28 AM UTC-5, Martin Alfke wrote:
>
> I prefer the each lambda over ensure_resource and create_resource.
> my 5pc.
>
In this particular case, the ensure_resource() call is inside a defined
type that is used both internally and externally, so I don't think
I prefer the each lambda over ensure_resource and create_resource.
my 5pc.
> On 20. Mar 2018, at 23:21, jcbollinger wrote:
>
> On Tuesday, October 17, 2017 at 7:59:16 AM UTC-5, jcbollinger wrote:
>
> Nothing has changed with `ensure_resource()`. The problem is not
On Tuesday, October 17, 2017 at 7:59:16 AM UTC-5, jcbollinger wrote:
>
> Nothing has changed with `ensure_resource()`. The problem is not its
> implementation details, but rather the nature of the usage modes the
> function is *designed* to support. The whole idea of it is flawed.
>
Funny
On Wednesday, October 18, 2017 at 6:38:51 PM UTC-5, Johan Fleury wrote:
>
> Le 17/10/2017 à 08:59, jcbollinger a écrit :
> > Nothing has changed with `ensure_resource()`. The problem is not its
> > implementation details, but rather the nature of the usage modes the
> > function is
It’s not wrong, but it’s order dependent. Assuming the two or more resource
definitions have some variance, you cannot guarantee the resource will be
realized as you intend. This you have to be very careful to not have
conflicting definitions that could flip flop over time or outright
conflict.
Le 17/10/2017 à 08:59, jcbollinger a écrit :
> Nothing has changed with `ensure_resource()`. The problem is not its
> implementation details, but rather the nature of the usage modes the
> function is *designed* to support. The whole idea of it is flawed. We can
> reprise that discussion if
I'm torn. While the duplication of resources across modules is a huge
issue, I'm not sure I'd be comfortable with opening this particular box
of Pandora's.
Imagining a world where users can (and will, trust me) declare the same
resource all over the place, I see much potential for bugs,
On Monday, March 31, 2014 3:55:03 PM UTC-5, Henrik Lindberg wrote:
Going forward, I think the Puppet Language should handle the situation
where more than one resource definition / class definition is made and
where the two are considered compatible (they describe the same
state). We are
On Monday, March 31, 2014 1:08:25 PM UTC-5, Dan Bode wrote:
That being said, there are two reasons it may be problematic.
1. Behavior depends on parse order - this is probably the best reason not
to use it.
And that is indeed an excellent reason not to use it.
The behavior of how
On 2014-01-04 15:22, jcbollinger wrote:
On Monday, March 31, 2014 3:55:03 PM UTC-5, Henrik Lindberg wrote:
Going forward, I think the Puppet Language should handle the situation
where more than one resource definition / class definition is made and
where the two are considered
I disagree that ensure_resource is evil and should not be used. It is
however, potentially problematic, and it's issues are worth discussing. It
was written (full disclosure by me) as an improvement over defined(). While
it is not perfect (it suffers from parse-order issues), it is intended as
an
On 2014-31-03 20:08, Dan Bode wrote:
I disagree that ensure_resource is evil and should not be used. It is
however, potentially problematic, and it's issues are worth discussing.
It was written (full disclosure by me) as an improvement over defined().
While it is not perfect (it suffers from
13 matches
Mail list logo