On Thursday, February 5, 2015 at 9:49:31 AM UTC-6, James Oden wrote: > > On Thu, Feb 5, 2015 at 9:52 AM, jcbollinger <john.bo...@stjude.org > <javascript:>> wrote: > <snip> > >> > >> In particular I don't see where it is getting that Exec[re-read apache > >> config] requires Class[App::Apache] (which itself contains > >> Exec[re-read apache config]). > > > > > > > > That dependency arises from the Exec resource being declared by > > Class[App::Apache]. You could read it as "Class[App::Apache] has not > been > > fully applied while Exec[re-read apache config] has not yet been > applied." > > > But that implies that any resource of a class has a dependency on its > class. Put another way every element of a container seems to have a > dependency on the container? Sounds very chicken and egg to me (i.e. > a built in cycle). > >
It's more complicated than that. The whole concept of containment requires some way of representing the *boundaries* of the container. Puppet has implemented that in various ways over time. The Exec -> Class relationship you see in your cycle is more technically a relationship between a contained resource and *the end* of its container. The end cannot (notionally) be applied until after all the contained resources have been applied. Puppet's representation of the beginning of a container is not relevant to your particular case. Be certain you understand that the dependencies we're talking about here are strictly order-of-application dependencies. That is, the chain expression "A -> B" expresses that in any given catalog run, correct/successful application of resource B depends on resource A must already have been applied in the same catalog run, but it has no other significance. There are other forms of dependency relevant to Puppet, too, but they have nothing to do with chaining or 'resource relationships'. > > > >> > >> But then it goes a step beyond and > >> states that Class[App::Apache], the dep I can't explain requires > >> Augeas[Change production to development in virtual hosts] causing a > >> loop. Near as I can tell App::Apache makes no requirements that > >> takes you directly back Augeas[Change production to development in > >> virtual hosts]. > > > > > > > > That's right in the Augeas resource you presented, specifically: > > > >> require => Class['app::apache'], > > > Yes but that is a separate dependency. I have declared: > > A->B > A->C > where B contains C > No. You have declared Class -> Augeas (require) Augeas -> Exec (notify) You also get Exec -> Class (containment) Voila! A cycle. > > 1. That should in no way imply B->A. > 2. Having a dependency on something contained in something else seems > odd, I don't think it's so odd, but it tends to produce practical problems -- exactly as you are currently experiencing. It can be done, but the problems get harder and harder to manage as your manifest set scales up and out. [...] > I understand the reasoning here, however in this case what is actually > going on is: > > 1) my real dependency is on app::apache which contains something I > want to > execute. > 2) I am executing something from app::apache. > > The central problem is entirely in the explicit declarations you have made. Your Augeas resource declares that class app::apache must be applied first. It also declares that a resource contained in that class must be applied later. It's like saying "I have a sandwich and chips for lunch. I'll eat my lunch before the meeting, and after the meeting I'll eat my sandwich." > What I was trying to do then was call the specific "command" I wanted > to run, and express the dependency that "command" had on its > container/package/class. > > Now if just "notify => blah" automatically creates a dependency on the > container of blah that is awesome. It doesn't, but I'm beginning to suspect that there is some lack of clarity (or perhaps lack of consistency) in this conversation regarding the direction of the relationship that the words "depends on" and "a dependency" is intended to convey. When I say "A depends on B", I mean B must be applied before A is, so B -> A in terms of Puppet's chain operators. > However the fact that I had > explicitly declared that dependency should at worst only cause a > duplicate dependency then, not somehow convolve a cycle from that > duplicate dependency. > > Puppet has no problem with duplicate relationships, but that's not what's going on here. > I like that way of approaching things. However, after listening to > your explanation it still feels like there is something amiss in the > handling of dependencies here. Two separate trees in a DAG should not > be merged together (unless I'm totally misunderstanding something). > > I don't understand what "merging" you think you see, unless it's that all order-of-application requirements for one catalog are represented in the same directed graph. Every relationship between any pair of resources is represented as an edge in it. Ordering requirements implied by containment are also expressed as edges in it. *Provided that graph is acyclic*, a global order of application for all resources is chosen consistent with it. Everything needs to be represented in that same graph for it to serve its purpose, so if you are arguing against that then yes, you are totally misunderstanding something. > That said, concerning the approach of notifying a class, when doing > this does this mean that all notifiable resources in the class get the > notify message too? > Yes. Likewise for notifying an instance of a defined type. Most of what we've been discussing is covered in the language reference, primarily in the section on resource relationships <https://docs.puppetlabs.com/puppet/3/reference/lang_relationships.html>, and a bit in the section on containment <https://docs.puppetlabs.com/puppet/3/reference/lang_containment.html>. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fb608c40-0132-4f17-961d-d0f1f4c13c52%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
