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. The anchor bug is something you actually have to work around. > 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. I don't know where this is coming from; I made no mention of differentiating between the two, and I can't imagine a solution that would or could do so. -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 -- 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.
