Dear all,
I have observed a behavior that doesn''t seem (to me) to match the
documentation. Specially, about tagging, the doc says:
"
Automatic Tagging
All language statements enclosed in a node, define or class structure (read
more about puppet control structures [[Language Tutorial]] ) will
automatically be tagged with the name of that statement. These automatically-
applied tags will be inherited by any object enclosed in that class,
regardless of the depth of enclosure.
"
But then I print the tags that are visible within each of the scopes:
node ''ANY'' {
}
node ''WN'' inherits ''ANY'' {
}
node ''wn01.domain'' inherits ''WN'' {
}
And inside each category I do:
$var = inline_template ("TAGS: <% tags.each do |tag| -%><%= tag
%> <% end
-%>")
notify { "$var": }
To print the visible tags.
And what I get is:
notice: TAGS: node wn01.domain class
notice: TAGS: node wn class
notice: TAGS: node any class
So, the tags are not inherited. Each node prints the tag that is declared in
its own node, but not those from the parent or the children. I have also tried
to do manual tags, and they are not inherited either.
Am I doing something wrong, or is "tagging" not well documented?
Thanks!
Pablo
--
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 Mar 6, 11:39 am, Pablo Fernandez <pablo.fernan...@cscs.ch> wrote:> Dear all, > > I have observed a behavior that doesn''t seem (to me) to match the > documentation. Specially, about tagging, the doc says: > > " > Automatic Tagging > All language statements enclosed in a node, define or class structure (read > more about puppet control structures [[Language Tutorial]] ) will > automatically be tagged with the name of that statement. These automatically- > applied tags will be inherited by any object enclosed in that class, > regardless of the depth of enclosure. > " > > But then I print the tags that are visible within each of the scopes: > > node ''ANY'' {} > > node ''WN'' inherits ''ANY'' {} > > node ''wn01.domain'' inherits ''WN'' { > > } > > And inside each category I do: > $var = inline_template ("TAGS: <% tags.each do |tag| -%><%= tag %> <% end > -%>") > notify { "$var": } > To print the visible tags. > > And what I get is: > > notice: TAGS: node wn01.domain class > notice: TAGS: node wn class > notice: TAGS: node any class > > So, the tags are not inherited. Each node prints the tag that is declared in > its own node, but not those from the parent or the children. I have also tried > to do manual tags, and they are not inherited either. > > Am I doing something wrong, or is "tagging" not well documented?Both, I think. The tagging documentation could be clearer, and probably it should avoid the word "inherited" because I think that may have misled you. On the other hand, I think your expectations are incorrect. It is "enclosed" objects that are documented to also get tagged, and I would not consider a node definition to be "enclosed by" another that inherits from it. John -- 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.
Hi,> > So, the tags are not inherited. Each node prints the tag that is > > declared in its own node, but not those from the parent or the > > children. I have also tried to do manual tags, and they are not > > inherited either. > > > > Am I doing something wrong, or is "tagging" not well documented? > > Both, I think. > > The tagging documentation could be clearer, and probably it should > avoid the word "inherited" because I think that may have misled you. > > On the other hand, I think your expectations are incorrect. It is > "enclosed" objects that are documented to also get tagged, and I would > not consider a node definition to be "enclosed by" another that > inherits from it.So, is there no "scope" when we talk about tags? Because I have noticed that, in more complex scenarios, tags are actually passed around (at this point I don''t know if I should call this inherited, enclosed, or what), like this: node ''ANY'' { include ssh::server # Default sshd_config } node ''WN'' inherits ''ANY'' { include ssh::enable_hostbased_auth } node ''ppwn01.lcg.cscs.ch'' inherits ''WN'' { } I print this within the ssh::enable_hostbased_auth context: TAGS: class ssh::enable_hostbased_auth ssh enable_hostbased_auth node wn So, I get both the tags WN and ssh::enable_hostbased_auth, it means it picked up the tags from the node, and from the class... but I don''t get the ssh::server, that''s comming from the parent of WN. What I need is a reliable way to do node groups, where I can specify some configuration parameters per group and per node, and the modules should be aware of that. Tags don''t seem apropiate, and possible neither variables (they difer within all scopes, and from the modules I can''t reference variables created on the nodes). What''s the right way to do this, then? Thanks! Pablo -- 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 Mar 7, 2:37 am, Pablo Fernandez <pablo.fernan...@cscs.ch> wrote:> > On the other hand, I think your expectations are incorrect. It is > > "enclosed" objects that are documented to also get tagged, and I would > > not consider a node definition to be "enclosed by" another that > > inherits from it. > > So, is there no "scope" when we talk about tags? Because I have noticed that, > in more complex scenarios, tags are actually passed around (at this point I > don''t know if I should call this inherited, enclosed, or what), like this: > > node ''ANY'' { > include ssh::server # Default sshd_config > > } > > node ''WN'' inherits ''ANY'' { > include ssh::enable_hostbased_auth > > } > > node ''ppwn01.lcg.cscs.ch'' inherits ''WN'' { > > } > > I print this within the ssh::enable_hostbased_auth context: > TAGS: class ssh::enable_hostbased_auth ssh enable_hostbased_auth node wn > > So, I get both the tags WN and ssh::enable_hostbased_auth, it means it picked > up the tags from the node, and from the class... but I don''t get the > ssh::server, that''s comming from the parent of WN.I wouldn''t say there''s no scoping involved, but I don''t follow how you envision involvement of scope leading to a different result than you see. I suspect you have the wrong mental model for node inheritance, and I speculate that the word "enclose" may have been chosen specifically to avoid implying the behavior you seem to have been expecting. Here''s what I think tag "inheritance" actually involves: 1) there is a tag associated with each node definition block 2) every class and resource declared directly within a node definition block acquires the containing block''s tag 3) there is a tag associated with each class 4) every class and resource declared directly within a[nother] class acquires all the tags on the declaring class, plus the tag associated with the containing class 5) neither node inheritance nor class inheritance factors into the analysis> What I need is a reliable way to do node groups, where I can specify some > configuration parameters per group and per node, and the modules should be > aware of that. Tags don''t seem apropiate, and possible neither variables (they > difer within all scopes, and from the modules I can''t reference variables > created on the nodes). What''s the right way to do this, then?No, tags are not the right tool for that kind of job. What you describe is exactly the sort of thing that Hiera is good for, however. Or extlookup() might do the job, too, but at this point it''s much more forward-looking to go with Hiera. John -- 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.