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.
The only way to force parse-time ordering right now is to do a direct
include, unfortunately.
--
Calvin Walton <calvin.wal...@kepstin.ca>
--
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.
