On 30 August 2013 11:14, R.I.Pienaar <[email protected]> wrote: > > > ----- 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"? >
No, I agree that is a pretty terrible user experience and not really applicable when classes are from different modules as you say. Was just commenting on that one of the solutions luke wrote works while the other doesn't really. But "works" and is a good thing to do are different things :) > > 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 > Agreed. -- Erik Dalén -- 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.
