On Saturday, March 16, 2013 9:49:24 AM UTC-5, Ryan Coleman wrote:
>
> Hi Tom,
>
> This definitely seems like a job for parameterized classes. This language
> feature allows you to define your model while expressing some parameters
> (data) that your model will use to modify its behavior.
>
Parameterized classes certainly provide a close match to the declaration
style the OP proposed, but since he already seems aware of them, I would
like to know why he is concerned that they may not be suitable. I suspect
the key is in his desire that "calling the class could be dynamic", but I'm
not sure what he means by that. Perhaps that the class(es) to be declared
is chosen at runtime?
Anyway, no job is appropriate for parameterized class declaration syntax
(so the OP is right to be doubtful). Parameterized classes themselves are
fine if data are bound via hiera (v3.0+ only), and maybe if they are bound
via an ENC, but it is both conceptually and practically problematic to bind
non-default data to classes via the DSL.
There are several ways in which the problem could be addressed via hiera,
both with and without parameterized class use. For example, if the
system_type dimension is going to be declared at node level for all nodes,
then I think it could be used to define a level of an Hiera hierarchy:
---:backends:
- yaml:yaml:
:datadir: /etc/puppet/hieradata
:hierarchy:
- %{system_type}
- common
Then configuration data would be recorded in YAML format in files (for
example) /etc/puppet/hieradata/{common,foobar,foobar2}.yaml.
Configured classes would obtain the data via calls to the hiera() function
(since there is no automated data binding in Puppet 2.7), such as this:
$myproperty = hiera('my_property_name')
Furthermore, if an important point is to select components (classes) to
declare based on system type, then the hiera_include() function fits the
bill exactly:
hiera_include('classes_key')
Hiera is an add-on for Puppet 2.7, but it is integrated into the core
starting with Puppet 3, so using it is forward-looking.
With all that said, this whole thing could as easily go in a completely
different direction. If we take a step back and look at the bigger picture
the OP presents, his module organization question might be as well or
better answered via Craig Dunn's "Roles and Profiles" pattern
(http://www.craigdunn.org/2012/05/239/). The OP's "system type" concept
seems an excellent match to Craig's "role". That does not invalidate any
of the foregoing comments, however, as hiera (and parameterized classes)
are pretty much orthogonal to roles and profiles.
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.
