On Apr 18, 4:50 am, Wilmer van der Gaast <[email protected]> wrote:
> Hello,
>
> To avoid silly micro-management of my "fleet" I've started using
> Puppet. Now I'm probably missing some "best practices".
>
> I'm currently getting a "Duplicate definition: Service[cron] is
> already defined" on my configs. Indeed there are two places that
> define the service. One's the duplicity module:
>
> # Ensure that cron is enabled and running.
> @service { cron:
> ensure => running,
> enable => true,
> }
>
> The other one is in my timezone update class:
>
> service { ["cron", "rsyslog", "atd"]:
> subscribe => [File["/etc/localtime"], File["/
> etc/timezone"]];
> }
>
> These are two *completely* independent things.
No, they're not. Both declare the resource Service['cron']. They
don't even declare the same properties for it, though it wouldn't
matter if they did. Perhaps you expected the properties to be
cumulative, but that's not the way Puppet works: you must set all the
properties of a resource at the point where you declare it (but see
below). For example:
# No effect on the client unless this resource is realized somewhere
@service { "cron":
ensure => running,
enable => true,
subscribe => [ File["/etc/localtime"], File["/etc/timezone"] ];
}
You can have multiple declarations of a resource as long as only one
is processed for each node. You can achieve that using conditional
statements in your manifests, or by putting the different declarations
into different classes, and making sure no node includes more than one
of those classes.
In some cases it may also be appropriate to override the properties of
resources declared in one class by creating a subclass. That's sort of
an exception to setting all the resource properties at the point of
declaration, but overriding does not involve separate resource
declarations.
> I suppose I can just
> remove the clause from duplicity since I don't see why I would not be
> running cron everywhere, but I still wonder how one is supposed to
> deal with a situation like this, since it will probably happen to me
> again.
I don't see why de-duplication need involve running cron everywhere.
1) You've already declared Service['cron'] virtually, so it will only
be managed on those nodes for which you realize it.
2) You could use one of the techniques described above to control
which of several Service['cron'] declarations is used on different
nodes (some of which might express ensure => stopped)
3) You could also use a selector to control a single declaration, like
so:
service { "cron":
... # other properties
ensure => $cron_should_not_run ? {
"yes" => stopped,
default => running
}
}
4) Or you could use extlookup():
service { "cron":
... # other properties
# depends on an external data file:
ensure => extlookup("cron_ensure")
}
5) Or there are other, more involved alternatives
Regards,
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
