----- Original Message ----- > From: "Erik Dalén" <[email protected]> > To: "Puppet Developers" <[email protected]> > Sent: Friday, August 30, 2013 5:07:46 PM > Subject: Re: Anchor pattern (was Re: [Puppet-dev] Puppet 4 discussions) > > On 30 August 2013 09:55, Luke Kanies <[email protected]> wrote: > > > 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…) > > > > Changing the include to require will cause "two" to happen before "one", > which is correct behaviour. > > Just adding Class[two] -> Class[three] inside class one fixes the order > though without using any anchors (in this example at least)
Sure, are you suggesting everyone who download a module from the forge study its internals, find all its contained classes and add these just so that require => Class["forge_module"] will "work"? In the example consider class one and two to be part of a forge module, and three to be my site specific module that I wish to have a dependency on the entirety of the forge module. The actual comments in anchor explains this well see https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/type/anchor.rb I want to just be able to say Class["ntp"] -> Class["mysql"] and not have to be concerned with the inner workings of the ntp module - here in the comments using 3 contained classes The only way today to do that is by adding all these anchor things - and that's the bug that leads to a horrible user experience and 100s of unneeded resources -- 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.
