On Mon, Oct 18, 2010 at 11:54:49PM +0200, Arnau Bria wrote: > My fear was that declaring File description in test1 could > change/overwrite general File description. In other words, > only one default possible.
Resource defaults respect traditional puppet scope rules. Resource collections, on the other hand, do not and have a global effect. I'm still not entirely sure if that is a good thing, although it can be abused in interesting ways. > > > We also have diff site.pp for diff porjects sharing main site.pp. Is > > > puppet evaluating site..p hiericaly? Or all site.pp are evaluated > > > with same importance. > > > > You're going to have to explain that in a little more detail. It's > > not clear how you have this organised. > ok. le me use site#.pp for future references: > My tree: > > ~puppet/manifests/site1.pp > /services/ > /SERA/site2.pp > /modules2 > /SERB/site3.pp > /modules3 > > -site1.pp defines some defaults and includes services/SERA/site2.pp and > service/SERB/site3.pp > -site2.pp defines its own defaults for modules2 > -site3.pp defines its own defaults for modules3 Do you mean "imports", or do you really mean "includes"? > > are defaults respected? If site1 defines mode 777, site2 defines mode > 750 and site3 mode 644, what is the default? I suppose you must really mean "include"; if you were importing those manifests and had defaults defined inside them, puppet would complain that you were defining defaults twice in the same scope and refuse to proceed. Unless the defaults are wrapped within classes. Your layout looks a little crazy. Why are you calling them all site1, site2, site3.pp? It's not a name with any special power, other than that /etc/puppet/manifest/site.pp is the default manifest for puppetd to run if you don't specify anything else. In any case, once puppet is given a starting manifest, what happens next is entirely down to your code. If you import code, it is "inserted" in place and treated as if you had typed the code directly into the file at the point where the import line is found. If you import code which contains a class, the class will not be evaluated until it is explicitly included. If you include a class that is not already in the code that has been read, puppet will try to autoload it (that is, it will look in some standard locations for manifests with specific names and *import* them if it finds them, then try and include the class - so the included class had better be in the file found by the autoloader). I hope that's a little clearer. Are you actually clear about the difference between importing and including? Which are you really doing there? Oh, and did you base that layout at all on the "style guidelines" from the wiki? Because I personally think those are terrible (sorry to whomever wrote that, but I really think it's an overcomplicated and undocumented mess, that recommended layout). Hmm. I think I spotted something. What do you mean "site2.pp defines its own defaults for modules2"? Is it posssible that site2.pp imports modules2? And that you have a bunch of classes defined in site2.pp? Because if that's the case, I have to tell you that the defaults in site2.pp are irrelevant. What counts is what the defaults are in the scope within which the classes are *included*. I'm only guessing about your code, though. I don't understand your layout and how the different parts of it are linked. -- Bruce I see a mouse. Where? There, on the stair. And its clumsy wooden footwear makes it easy to trap and kill. -- Harry Hill -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
