On Dec 17, 9:19 pm, Alexandre <alexandre.fou...@gmail.com> wrote:
> it was because the case
>
> $mysql_enabled = 1
> class mysql::server {
> service{mysqld: blablabla activate}
>
> }
>
> class stripdown{
> if $mysql_enabled == 1 {
> service{mysqld: blablabla deactivate}
> }
>
> }
>
> node somenode {
> include mysql::server
> include stripdown
>
> }
>
> So you see in the case above, the parser will fail because service
> [mysql] is included and defined twice (of course, since it is grammar
> parser and not an AI ;-). But it would have worked if executed
> ( But i know the whole thing with variables is maybe a wrong
> implementation of the problem )
I agree that variables are not likely constitute a viable approach to
solving this problem. I'm also not all that enthusiastic about the use
of a general stripdown, but that's a personal preference thing. Since
you seem to be intent on that manner of solution, have you tried
something along these lines:
class stripdown {
# turn off everything we care about managing
service { "mysqld": <deactivate> }
service { "apache": <deactivate> }
...
}
class mysql::server inherits stripdown {
Service ["mysqld"] { <activate> }
}
class apache::server inherits stripdown {
Service ["apache"] { <activate> }
}
node foo {
include stripdown
}
node bar {
include stripdown
include mysql::server
}
node baz {
include stripdown
include mysql::server
include apache::server
}
In other words, all your some_facility::server classes inherit from
the same general stripdown and override different (that's important)
resources. Each node then includes the stripdown and the service-
specific classes for those services it should run.
--
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.
