On Dec 9, 10:19 am, Silviu Paragina <sil...@paragina.ro> wrote:
> I think this is the usual style of defining stuff in puppet as I've seen
> it in a lot of places.
I have often seen the model of
class some_facility::base {}
class some_facility::server {}
class some_facility::client {}
I have not noticed class inheritance routinely being used in such a
setup, but I may have just overlooked it. If client and server
classes simply "include" the base class, though, then that achieves
everything that inheriting would do except allowing resource
overrides.
I don't have any objection to the client and server classes both
inheriting the base class, but it is conceptually wrong for server to
inherit client, for the server machines do not need to also be
clients.
For general-purpose overrides (as opposed to node-specific ones), the
best practices recommend something of the form
class some_facility::server::disabled
inherits some_facility::server { [resource overrides here] }
> Now if you include both s_test1::stripdown and s_test::server server
> will take precedence. (actually it may start as s_test1::stripdown and
> then "add to it" s_test1::server, but the behavior is respected no
> matter what the order of includes).
Somewhat to my surprise, that works. On the other hand, the fact that
I find it surprising is enough reason for me, personally, to never use
that motif. To be clear: the surprising thing to me is that Puppet
does not complain about including both s_test1::stripdown and
s_test1::server in the same catalog, even though they define
conflicting properties for Service["mysqld"]. (It can be made to
complain about conflicting properties if you structure the classes and
overrides differently, though.)
How to approach this kind of issue is surely a matter of opinion and
preference, but for me it doesn't make sense to have a blanket disable
for a service that isn't necessarily even installed. Thus, I would do
something more like this:
class mysql::server {
package { "mysql-server": ensure => "latest" }
service { "myslqd":
name => "mysql",
require => Package["mysql-server"],
enable => true,
ensure => "running",
}
class mysql::server::disable inherits mysql::server {
Service { "mysqld": enable => false, ensure => "stopped" }
}
There are then three options for each node:
1) The mysql server is unmanaged, or forced not present if package
purging is enabled. This happens if neither mysql::server nor
mysql::server::disable is included.
2) The mysql server is installed, enabled, and running. This happens
if mysql::server is included and mysql::server::disable is not.
3) The mysql server is installed but disabled and not running. This
happens if mysql::server::disable is included.
YMWV
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
