On Thursday, March 28, 2013 5:21:51 AM UTC-5, blalor wrote:
>
> On Mar 27, 2013, at 2:32 PM, Ellison Marks <gty...@gmail.com <javascript:>>
> wrote:
>
> If your role class declares other classes you probably being bitten by
> http://projects.puppetlabs.com/issues/8040. That is, and classes declared
> in the role class are not confined by the dependency graph. It's something
> they're working on fixing, but in the meantime, the recomendation is to use
> the anchor pattern.
> http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern. The
> achor resource type comes from the stdlib, IIRC.
>
>
> Thanks, Ellison. Yes, other classes are declared. This really violates
> the principle of least surprise. I'll give the anchors a try today,
> hopefully.
>
I understand that you were surprised by the behavior, but you need to
understand what's going on here. Although classes (and definitions) are
sometimes described as "containers", they are not *exclusive* containers
when it comes to classes. Multiple classes and definitions may all declare
the same class, so there would be an even bigger mess (of dependency
cycles) if all relationships were automatically forwarded from classes to
their declared classes.
Indeed, a key thing to understand is that classes are containers for *
resources*, but classes themselves should not be considered resources.
Implementation details notwithstanding, classes behave rather differently
than ordinary resources. They are especially distinguished by having no
client-side behavior whatsoever, and even more so by the fact that they
*do*have significance to the master. Then there's the whole multiple
declaration thing. There are some other behavior differences that could
surprise you, too, if you don't distinguish classes from resources.
Although I usually make this recommendation for different reasons, it is a
good idea to avoid using resource-like, parameterized-style class
declarations (class { 'foo': ... }) and instead declare classes via the
'include' (or 'require') function. Bind custom class parameter values via
hiera where needed, or even drop class parameters altogether and just use
hiera explicitly. This has functional benefits, but in this case I'm
recommending it as a means to help you remember that classes are not
(normal) resources.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
