Hi all, I''m wondering what puppet does if I define two diff type defaults (like file mode, owner) in two different classes. I''m trying to figure it out by running puppet and watching some file perms, but I see no changes. But I''m not sure that my desired behaivour is the one puppet follows. Is each default evaluated for each class? or is one default overwriting other''s one? 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. TIA, 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Bruce Richardson
2010-Oct-18 21:24 UTC
Re: [Puppet Users] setting type defaults in some classes
On Mon, Oct 18, 2010 at 10:58:56PM +0200, Arnau Bria wrote:> Hi all, > > I''m wondering what puppet does if I define two diff type defaults (like > file mode, owner) in two different classes. I''m trying to figure it out > by running puppet and watching some file perms, but I see no changes.If you''re seeing no changes, you aren''t testing carefully enough. See following example: ----------------------------------------------------------------------- File { ensure => ''file'', mode => ''750'' } class test1 { File { mode => ''751'' } file { ''/tmp/test1'': } include test3 } class test2 { file {''/tmp/test2'': } } class test3 { file {''/tmp/test3'': } } file { ''/tmp/toplevel'': } include test1 include test2 ----------------------------------------------------------------------- In the above example, files test2 and toplevel have 750 permissions, test1 and test2 have 751. Is this not what you find? Should answer your questions. Resource defaults are inherited. So be careful.> > 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. -- 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, 18 Oct 2010 22:24:28 +0100 Bruce Richardson wrote: Hi Bruce,> > I''m wondering what puppet does if I define two diff type defaults > > (like file mode, owner) in two different classes. I''m trying to > > figure it out by running puppet and watching some file perms, but I > > see no changes. > > If you''re seeing no changes, you aren''t testing carefully enough. See > following example:I''ve wrongly expressed myself. I was afraid of seeing some kind of flip-flop on file perms.> ----------------------------------------------------------------------- > > File { > ensure => ''file'', > mode => ''750'' > } > > class test1 { > File { mode => ''751'' } > file { ''/tmp/test1'': } > include test3 > } > > class test2 { > file {''/tmp/test2'': } > } > > class test3 { > file {''/tmp/test3'': } > } > > file { ''/tmp/toplevel'': } > > include test1 > include test2 > > ----------------------------------------------------------------------- > > In the above example, files test2 and toplevel have 750 permissions, > test1 and test2 have 751. Is this not what you find? Should answer^^^^^^^^ test3 ?> your questions.I think it does: each class can have its own defaults. (which is my desired behave). My fear was that declaring File description in test1 could change/overwrite general File description. In other words, only one default possible.> Resource defaults are inherited. So be careful. > > > > > 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 are defaults respected? If site1 defines mode 777, site2 defines mode 750 and site3 mode 644, what is the default? *My tests show that a file in module2 has perms 750, one in module3 has perms 644, which is desired. but we''re seeing some rare situacion where some files have rare perms, and we''re wondering if this schema is producing problems or not. Many thanks for your reply, 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Bruce Richardson
2010-Oct-18 23:07 UTC
Re: [Puppet Users] setting type defaults in some classes
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 modules3Do 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Bruce Richardson
2010-Oct-19 10:06 UTC
Re: [Puppet Users] setting type defaults in some classes
On Tue, Oct 19, 2010 at 11:32:26AM +0200, Arnau Bria wrote:> 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?Unfortunately, I don''t think there is great documentation out there; the core development team is too busy and so are most of the users. Documentation lags behind. I''d love to add better documentation to Puppet but I have a very busy and stressful job, so I fail too. But in any case...> > 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.Great! Now that you understand better how imports and includes work, you''re answering your own questions. I bet you can work out a better way of laying out your manifests for yourself. The best advice I can give you is to work with the way puppet module/class autoloading works, not against it.> > 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.If there is a conflict between an already declared default and a new default, the new default wins. If there is no conflict, they are added together. If you go back to my example, I set a default of "ensure file" at the top level. Because none of the later defaults had an "ensure" parameter, all files inherited that default. I also set "mode = 750" at the top level, but in some places I later declared "mode" again. In such cases, the declaration in the most immediate scope always wins. -- Bruce What would Edward Woodward do?
Nigel Kersten
2010-Oct-19 15:50 UTC
Re: [Puppet Users] setting type defaults in some classes
On Tue, Oct 19, 2010 at 3:06 AM, Bruce Richardson <itsbruce@workshy.org> wrote:> On Tue, Oct 19, 2010 at 11:32:26AM +0200, Arnau Bria wrote: >> 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? > > Unfortunately, I don''t think there is great documentation out there; the > core development team is too busy and so are most of the users. > Documentation lags behind. I''d love to add better documentation to > Puppet but I have a very busy and stressful job, so I fail too. But in > any case...Even if people don''t have time to provide documentation, it would be extremely helpful if people filed clear bugs/features against the documentation so we know what you really want to see. This also means when someone decides to work on improving the docs, there is a reasonably clear list of priorities. http://docs.puppetlabs.com/contribute.html> >> > 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. > > Great! Now that you understand better how imports and includes work, > you''re answering your own questions. I bet you can work out a better > way of laying out your manifests for yourself. > > The best advice I can give you is to work with the way puppet > module/class autoloading works, not against it. > >> >> 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. > > If there is a conflict between an already declared default and a new > default, the new default wins. If there is no conflict, they are added > together. If you go back to my example, I set a default of "ensure > file" at the top level. Because none of the later defaults had an > "ensure" parameter, all files inherited that default. I also set "mode > = 750" at the top level, but in some places I later declared "mode" > again. In such cases, the declaration in the most immediate scope > always wins. > > -- > Bruce > > What would Edward Woodward do? > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAky9bZQACgkQtkVqYTMBSwFdBACeI6QKolxGcX0CarlNOSpoJLAH > WiYAn3YGrDGWqt6etbuECtja6SWPQAoH > =Eqvm > -----END PGP SIGNATURE----- > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.