----- Original Message -----
> From: "Luke Kanies" <[email protected]>
> To: [email protected]
> Sent: Friday, August 30, 2013 3:55:57 PM
> Subject: Re: Anchor pattern (was Re: [Puppet-dev] Puppet 4 discussions)
>
> On Aug 30, 2013, at 1:05 AM, "R.I.Pienaar" <[email protected]> wrote:
>
> >
> >
> > ----- Original Message -----
> >> From: "Luke Kanies" <[email protected]>
> >> To: [email protected]
> >> Sent: Thursday, August 29, 2013 11:27:00 PM
> >> Subject: Re: Anchor pattern (was Re: [Puppet-dev] Puppet 4 discussions)
> >>
> >> On Aug 29, 2013, at 12:24 PM, John Bollinger <[email protected]>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Wednesday, August 28, 2013 5:56:45 PM UTC-5, Andy Parker wrote:
> >>> On Wed, Aug 28, 2013 at 3:22 PM, Luke Kanies <[email protected]>
> >>> wrote:
> >>> On Aug 28, 2013, at 12:38 PM, Andy Parker <[email protected]> wrote:
> >>>> On Wed, Aug 28, 2013 at 10:20 AM, Luke Kanies <[email protected]>
> >>>> wrote:
> >>>> On Aug 28, 2013, at 8:45 AM, Andy Parker <[email protected]> wrote:
> >>>>
> >>>>> * #8040 - anchor pattern. I think a solution is in sight, but it
> >>>>> didn't make 3.3.0 and it is looking like it might be backwards
> >>>>> incompatible.
> >>>>
> >>>> Why would it be incompatible?
> >>>>
> >>>> That implies that we can't ship it until 4.0, which would be a tragedy
> >>>> worth fighting hard to avoid.
> >>>>
> >>>>
> >>>> The only possible problem, that I know of, would be that it would change
> >>>> the evaluation order. Once things get contained correctly that might
> >>>> cause problems. We never give very strong guarantees between versions of
> >>>> puppet, but given the concern with manifest order, I thought that I
> >>>> would
> >>>> call this out as well.
> >>>
> >>> Do you mean, for 2 classes that should have a relationship but currently
> >>> don't because of the bug (and the lack of someone using an anchor pattern
> >>> to work around the bug), fixing that bug would cause them to have a
> >>> relationship and thus change the order?
> >>>
> >>>
> >>> No that shouldn't be a problem. I think we will be using making the
> >>> resource syntax for classes ( class { foo: } ) create the containment
> >>> relationship. That doesn't allow multiple declarations and so we
> >>> shouldn't
> >>> encounter the problem of the class being in two places.
> >>>
> >>>
> >>> But it does allow multiple declarations, so long as only the first one
> >>> parsed uses the parameterized syntax. There can be any number of other
> >>> places where class foo is declared via the include() function or
> >>> require()
> >>> function.
> >>>
> >>>
> >>> That is, you're concerned that the bug has been around so long it's
> >>> considered a feature, and thus we can't change it except in a major
> >>> release?
> >>>
> >>>
> >>> More of just that the class will start being contained in another class
> >>> and
> >>> so it will change where it is evaluated in an agent run. That could cause
> >>> something that worked before to stop working (it only worked before
> >>> because of random luck). I'm also, right now, wondering if there are
> >>> possible dependency cycles that might show up. I haven't thought that one
> >>> through.
> >>>
> >>>
> >>> Yes, it is possible that dependency cycles could be created where none
> >>> existed before. About a week ago I added an example to the comments
> >>> thread on this issue; it is part of a larger objection to the proposed
> >>> solution: http://projects.puppetlabs.com/issues/8040#note-35. I also
> >>> included a proposed alternative solution that could go into Puppet 3.
> >>
> >> As mentioned in my other email, the solution to this problem should not in
> >> any way require changes to containment semantics, and certainly shouldn't
> >> require class evaluation to indicate class containment. As I said, it
> >> used
> >> to do that for the first instance (but not for second, which led to some
> >> inconsistencies and surprises, which is why I removed it). These days,
> >> though, in general classes only contain resources, not other classes.
> >> What
> >
> > I am not sure I follow and have missed some of this thread while on hols
> > but
> > here is why people use the anchor pattern:
> >
> > class one {
> > include two
> >
> > notify{$name: }
> > }
> >
> > class two {
> > notify{$name: }
> > }
> >
> > class three {
> > notify{$name: require => Class["one"]}
> > }
> >
> > include one, three
> >
> > $ puppet apply test.pp
> > Notice: /Stage[main]/One/Notify[one]/message: defined 'message' as 'one'
> > Notice: /Stage[main]/Three/Notify[three]/message: defined 'message' as
> > 'three'
> > Notice: /Stage[main]/Two/Notify[two]/message: defined 'message' as 'two'
> > Notice: Finished catalog run in 0.11 seconds
> >
> > The desired outcome is that Notify[two] is before Notify[three]
> >
> > So unless I am reading you wrong, the anchor pattern is used specifically
> > because
> > today many people have classes contained in other classes and it does not
> > work
> > as desired.
>
> If you want a specific order, there are plenty of tools for achieving that;
> in this particular case, you should use 'require two' instead of 'include
> two' (or include it, then use something like Class[two] -> Class[three],
> but…)
>
> I.e., there's nothing to work around in this case, it already works.
Yet this is the reason people use the anchor pattern, they would rewrite class
one as:
class one {
anchor{"one_start": } ->
notify{$name: } ->
class{"two": } ->
anchor{"one_end": }
}
every module author ever have to do all this stuff so that require => Class[one]
would do the expected thing.
And that's the behavior that should be fixed when people talk about fixing the
anchor pattern bug. So that the module without all the anchor/order/etc mess
would
just do the right thing - the right thing being if class A include class B then
requiring class A should also require class B and everything in it.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
