On Monday, January 28, 2013 11:17:03 AM UTC-6, Calvin Walton wrote:
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.
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.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 /
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 isinclude, unfortunately.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
