On Tue, 19 Oct 2010 00:07:50 +0100 Bruce Richardson wrote: Hi Bruce, I'd like to thanks the time you take for answering my question.
> > ~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"? we do imports, no includes. Sorry. > 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. Well, unfortunately for us no resource overwrite happened so we saw no error. If overwriting defaults, and as you well say, puppet complains. (We had, i.e., default service => path in site1.pp and ensure => enable in site2.pp). > Your layout looks a little crazy. Why are you calling them all site1, > site2, site3.pp? Just following puppet "schema", nothing else. It's for our commodity: Diff SER are managed by diff pepople, so each one can modify its own "site" and import its own modules (They also have its own nodes.pp). If we want to add a project, we only have to add new SER with its own site, node, ... and then "import" new site/node in site1/node1. Is like having a big puppet with all modules/classes available everywhere but divided in sub-trees. I don't remember from where I took the idea... but seems that I chose wrong place :-) What do you recommend me? any doc to follow? [...] > 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. Reading your answer (and if I thought a little more about it before), my question could be answered by myself. As you say import "inserts" code, so having 2 diff defaults in 2 diff sites does not make much sense, or does not behave as I wish. > 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). Well, after my question and your answers, we could say that not much :-) Or basic idea. I already asked it some time ago: http://www.mail-archive.com/puppet-users@googlegroups.com/msg04826.html and read some doc in puppet site. > Hmm. I think I spotted something. What do you mean "site2.pp defines > its own defaults for modules2"? At this point, that conf has no sense. > Is it posssible that site2.pp imports modules2? > And that you have a bunch of classes defined in site2.pp? Yes, it does. I.e we define classes under modules2/mod1/manifests/init.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*. Mmmm... I'm not sure if I got you, but they're important: site1.pp: File { mode => 666, } services/workernode/modules/computing_bacula/manifests/init.pp file { 'kaka': name => '/root/kaka', ensure => present; } On client: notice: /Stage[main]/Computing_bacula/File[kaka]/ensure: created # ls -lsa /root/kaka 0 -rw-rw-rw- 1 root root 0 Oct 19 11:15 /root/kaka If I redefine File defaults in comuting_bacula (in the class, not module) it's evaluted and it's more important: class computing_bacula { File { mode => 755 } } File { 'kaka' } on client: notice: /Stage[main]/Computing_bacula/File[kaka]/mode: mode changed '666' to '755' So class defaults "are more important" than site dfaults. > I'm only guessing about your code, though. I don't understand your > layout and how the different parts of it are linked. So, maybe now you understand my original question :-) Maybe it's because my wrong use of imports/includes and defaults definitions. Thanks for your replies, Arnau -- 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.
