My experience with it is that it only includes declared/included classes
(which matches my desire anyway), but that the list of classes is ...
somewhat random. It will always include the classes in the chain of the
test, but other classes are more random. A short example:
class one{ include two;include three}
class two {notice "two: $classes"}
class three {notice "three: $classes" }
There will be two notices printed, with two possible variations each,
depending upon what the compiler chooses to do this time:
two: one two
two: one two three (order may vary)
three: one three
three: one two three (again, order may vary)
In my case, I'm evaluating template("ssh/sshd_config.erb") inside my
"minimal" class, because *every* host has ssh, but the set of users allowed
to login to each host varies depending upon the total set of classes
involved. If I include role::web_server, then the web server manager needs
to be able to login. If I include role::dev, then all of the developers
should have access. A host may have multiple roles, and thus the need for
some reasonable way of determining what classes are associated with the
node. When I ran 2.6.1, this worked as desired (I *think*). After updating
to 2.6.3, it almost never worked as desired.
If I had to guess, I'd say that the evaluation of templates (and possibly
inline_templates) previously happened after the first pass at parsing when
the list of classes would be complete except for those whose inclusion is
predicated on the inline_template() evaluations. Now it's clear that all
the templates (inline or not) are evaluated at the point they are
encountered, which should be(!) in a fixed order, though it seems (sorry, I
haven't exhaustively tested) to vary somewhat from run to run.
On Wed, Feb 2, 2011 at 6:00 PM, Nick Fagerlund <
nick.fagerl...@puppetlabs.com> wrote:
> *EXPERIMENTS*
>
> Huh, it seems to return the DECLARED classes, not the defined ones,
> i.e. it can only see the modules and classes that are being applied to
> this particular node. OK, I could see an argument for that making
> sense. BUT: It also includes the names of any `node` constructs that
> match it (these are nodes defined in manifests, not from an ENC), and
> for some reason classes set via an ENC show up twice. I don't
> understand that. Also, there's one mystery class from Mars in there
> called "settings." What's THAT about.
>
> On Feb 2, 5:50 pm, Nick Fagerlund <nick.fagerl...@puppetlabs.com>
> wrote:
> > On it. (Thanks for the example, Dan; that's pretty sweet.)
> >
> > Brian, what problem do you tend to see with the classes array? Does it
> > look like an order dependency? Is it just a crapshoot as to whether a
> > given class is in the list, or is there a method to it?
> >
> > On Feb 2, 5:18 pm, Brian Gallew <g...@gallew.org> wrote:
> >
> >
> >
> >
> >
> >
> >
> > > On Feb 2, 2011, at 4:57 PM, John Warburton wrote:
> >
> > > > I would love to see that inhttp://
> docs.puppetlabs.com/guides/templating.htmlinthe "Access to defined tags
> and classes" section. I have created a ticket for that -
> https://projects.puppetlabs.com/issues/6124
> >
> > > Sadly, there's also a great need to update that section to reflect the
> reality that the classes variable can never be relied upon to be in any way
> complete.
>
> --
> 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+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
