"Then we're not on the same page, when people want the anchor pattern gone they want what you're calling the feature implemented."
+1 to this. This is exactly what Markus, Luke, and I were discussing back in 2010. Trevor On Fri, Aug 30, 2013 at 1:40 PM, R.I.Pienaar <[email protected]> wrote: > > > ----- Original Message ----- > > From: "Luke Kanies" <[email protected]> > > To: [email protected] > > Sent: Friday, August 30, 2013 6:34:13 PM > > Subject: Re: Anchor pattern (was Re: [Puppet-dev] Puppet 4 discussions) > > > > On Aug 30, 2013, at 9:14 AM, "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'm suggesting that everyone who builds a module actually set up > > appropriate dependencies between the classes. If you've got a top-level > > class, it should be listed as requiring the classes it requires. > Shouldn't > > the module author be responsible for getting that right? > > > > The only other reasonable choice I can come up with is to create > something > > like a 'package' type, where any kind of class declaration (either with > > 'include' or 'class {}') results in a containment relationship. That's > more > > of a feature than a bug thing, right? > > Then we're not on the same page, when people want the anchor pattern gone > they > want what you're calling the feature implemented. > > From Andy's earlier email here - that's what he also think. > > If this is up to the module author - as it is today - then what you're > promoting > is a scenario where 100s of LOC is dedicated to code thats there for no > other reason > than to facilitate ordering and containment and this is a missfeature. > People do > not understand it, do not anticipate the current behavior and its hurting > the > ability to make reusable modules easily. > > > > > > 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 > > > > Why can't you use requires? > > Because requires is requires and not contains. > > class one { > include two > > notify{$name: } > } > > > should contain Class[two] the same way it contains Notify[one] - and thus > all > the resources in two and any classes it includes and so forth and so on. > > But as Andy explains in detail and I only hinted at this leads to trivial > loops > unless we only do this with the resource like includes. > > -- > 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. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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.
