Option A, 100%.
Why change your coding pattern just because a module isn't from the Forge?
Who knows, maybe one day you'll post it yourself on the Forge!
Sometimes I do the full parameter workup like in your example, and
sometimes I just use `include` and let Hiera fill in the parameters,
wit
Make a module. When the complexity of managing the modules resources
within your environment become complex enough to warrant it, make a
profile containing your business logic to wrap that module.
The cons in your first example, extra work and duplication, do not
exist. Profiles are entirely o
On Tuesday, June 9, 2020 at 6:22:55 AM UTC-6, A Manzer wrote:
>
> Option A, 100%.
>
> Why change your coding pattern just because a module isn't from the
> Forge? Who knows, maybe one day you'll post it yourself on the Forge!
>
I try to write modules as if I am going to post them to the Forge.
>
> Either you need to manage that
> complexity or you don't.
>
You are right and we have already decided that RP is warranted. So yeah,
module + profile.
Thank you for your input,
-Alan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To
>
>
> I've done the same thing in the past, just use Hiera to provide params to
> technology modules. It feels a little off, it seems like the "right" way
> is to wrap a technology module in a profile and then put the profile::
> params in Hiera.
>
Yeah, you're right that the "right" way is w
Role/Profiles not binary choice within the system, it's "does this
specific module in my environment need business logic.
Example from my environment. Most of the time you don't need to care
about chrony. It runs, no logic required. In our case we want to sync
with the ptp clock in certain cas
