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? > 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? -- 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.
