As was discussed above it does not fit well w/ R&P but I think I am going
to do something like #2.
class wazuh(
Boolean $manager = false,
) {
if $manager {
include wazuh::manager
} else {
include wazuh::agent
}
}
# data/nodes/my-manager-node.example.com.yaml
wazuh::manager: true
On Wednesday, November 6, 2019 at 2:55:02 AM UTC-7, Karsten Heymann wrote:
>
> Am Mi., 6. Nov. 2019 um 01:54 Uhr schrieb Alan Evans <alanw...@gmail.com
> <javascript:>>:
> > Sorry, I misread. I see what you're saying. This is like what I was
> proposing w/ hiera. The trouble is that it's not really R&P then as has
> been brought up by jcbollinger.
>
> I think there are at least three ways to handle this, and all of them have
> their valid uses:
>
> 1) Explicitly include the worker profile in every role but the master role
> - pro: you need no logic to disable the worker profile in the master role
> - con: A lot of repetition in the other roles
> 2) Add a "disable switch" hiera variable to the worker profile and then
> include it in the base.pp. For the master node, you disable the worker
> profile via the hiera switch and explicitly include the master profile
> - pro: It is possible to include the
> - con: You need to wrap the code in the worker profile into a large if
> not $disabled { ... } clause
> 3) Create a wrapper profile for master and worker that conditionally,
> depending on a hiera variable, load one class or the other. That variable
> could be a $service_type = master|worker enum or the fqdn of the master
> server to compare again in the wrapper class if the master name is already
> needed i.e. for configuring the workers: if $facts['fqdn'] == $mastername
> { include profile::service::master } else { include profile::service::slave
> }
> - pro: You need only a single include in the role or base.pp for every
> server somehow related to that service, be it master or worker
> - con: In the role class it is not directly visible if the server is a
> master or a worker.
>
> Which one of these to use (if any) depends on your preferences and
> situation, of course.
>
> Best regards
> Karsten
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/87e7c3f5-5a4e-4e85-82e5-987ef91b1fda%40googlegroups.com.
