On Monday, January 28, 2013 11:17:03 AM UTC-6, Calvin Walton wrote:
>
> On Mon, 2013-01-28 at 09:12 -0800, Luke Bigum wrote:
> > On Monday, January 28, 2013 5:00:24 PM UTC, Ti Leggett wrote:
>
> > However, let me warn you against going overboard with having classes
> > include other classes from other modules. It can be annoying to track
> down
> > where resources coming from for any given node if you've got cross
> module
> > inclusion: kibana includes httpd includes mod_ssl includes openssl
> includes
> > somethingelse includes ... How did this get on here?
> >
> > A cleaner way might be to declare cross module relationships using the
> > Arrow operators:
> >
> > class kibana::apache {
> > Class[apache::params] -> Class[kibana::apache]
> > ...
> > }
> >
> > And then you make a house rule to have all your classes instantiated in
> > your node definitions:
> >
> > node woof {
> > class kibana
> > class apache::params
> > }
> >
> > If apache::params is missing, you'll get an error saying so. It also
> fits
> > rather nicely into an ENC if you want to go in that direction now /
> later.
>
> While this is a good idea in general, it doesn't solve Luke's original
> problem. In order to reference a variable $apache::params::something
> from inside the kibana::apache class, you need the apache::params class
> to be parsed on the puppet master before the kibana::apache class. This
> is a parse-time ordering problem, not a run-time ordering problem.
>
Exactly.
>
> The only way to force parse-time ordering right now is to do a direct
> include, unfortunately.
>
>
Yes, but I'm not sure I would say "unfortunately" there. The problem is
not so much with any limitation of Puppet DSL in this area, but rather an
issue of module design and manifest set architecture.
I mean, one should be very careful and deliberate about designing modules
such that their classes need to rely on class variables of other modules'
classes. Indeed, it is probably a poor idea to implement such a design
unilaterally -- instead, the module providing the class variables should be
designed and implemented in anticipation of that usage as well. That
probably means centralizing all variables intended for cross-module
reference in one well-known class, documenting their names and value
ranges, and committing to avoiding incompatible changes there.
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.
