On Aug 1, 1:10 pm, hornet136 <hornet...@gmail.com> wrote:
> I want to start out with an apache class that will disable all modules
> except for a pre-defined list, thus establishing a baseline of active
> modules.
> Then as needed, other classes could enable a module that they require
> that would have been disabled by the baseline state.
> Its possible several classes may try to enable the same module (1 or
> more classes needing module1 could be on a single node)
>
> What is the 'right' way to do this? I've played with virtual
> resources and class inheritance.
> I hope to avoid class inheritance if possible as virtual resources
> seems to be the correct way to do this kind of thing.
>From your description, class inheritance seems clearly to be the
correct way to do what you want, especially if the only alternative
being considered is virtual resources. The pattern to recognize is
that you want all nodes to have certain resources, but you want to
assign different property values to some of those resources on certain
nodes. Sometimes you can handle that kind of situation with
conditionals, extlookup(), or class parameters, but your case
practically screams for class inheritance.
Virtual resources, on the other hand, are for when only some nodes
will want certain resources, and they should not be defined at all for
other nodes. As a special case, virtual resources are good for when
there are multiple distinct, non-exclusive places where a decision to
assign the same resource to a node can be made. Note the distinction
with respect to your requirements: resources defined differently
(using inheritance) vs. resources maybe not defined at all (using
virtual resources).
> I however have had troubles with doing that and have ultimately ended
> up with the following using inheritance:
>
> class apache2::modules {
>
> # list apache modules to enable
> $enable_apachemods = [ "module1", "module2", "module3", ]
>
> # list apache modules to disable, basically all modules would be
> listed here by default
> $disable_apachemods = [ "module4", "module5", "module6", ]
>
> # Process list of apache modules to enable
> a2mod { $enable_apachemods: ensure => "present", notify =>
> Exec["apache2reload"] }
>
> # Process list of apache modules to disable
> a2mod { $disable_apachemods: ensure => "absent", notify =>
> Exec["apache2reload"] }
>
> }
>
> Then as I have other classes defined that require a specific apache
> module they should simply set it to 'present'.
>
> class application1 {
> include apache2::modules::app1
> ...
>
> }
>
> class apache2::modules::app1 inherits apache2::modules {
> A2mod['module4'] { ensure => 'present', require =>
> Package['modulepackage'] }
>
> }
>
> class application2 {
> include apache2::modules::app2
> ...
>
> }
>
> class apache2::modules::app2 inherits apache2::modules {
> A2mod['module4'] { ensure => 'present', require =>
> Package['modulepackage'] }
>
> }
>
> I get the following error when I do it this way:
>
> Error 400 on SERVER: Parameter 'ensure' is already set on
> A2mod[module4]... cannot redefine at....
Yes, no node can include two different subclasses that override the
same property of the same resource, so you woul get that error when a
node includes both Class['application1'] and Class['application2'].
You're pretty close, though. The correct way to approach this is to
generalize the subclasses so that they can be shared:
class apache2::modules::module4 inherits apache2::modules {
A2mod['module4'] {
ensure => 'present',
require => Package['modulepackage']
}
}
class application1 {
include 'apache2::modules::module4'
}
class application2 {
include 'apache2::modules::module4'
}
Note how this also provides better encapsulation apache's resources,
in that application-related classes don't need to know anything about
the internal details of the apache2::modules class. Note also how the
application1 and application2 classes now read so cleanly and clearly.
If there are groups of modules that you *always* want to enable
together, then you can do that via a single subclass, following the
general model above. Beware, however, of "always" some day becoming
"usually".
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
