----- 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.
Also I think fixing this only for the new resource like syntax and not for
include would be a mistake - though i can see why that would be the chosen
path as doing it otherwise would easily create loops etc.
--
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.
