>From my understanding the contains ensures that all work in that class (and
>sub classes) is completed before moving on to the next contains class. With
>include I believe puppet could move on to the next class. The contains works
>nice with the install > config > service model.
-Kurt
From: puppet-users@googlegroups.com <puppet-users@googlegroups.com> On Behalf
Of A Manzer
Sent: Tuesday, June 9, 2020 7:23 AM
To: Puppet Users <puppet-users@googlegroups.com>
Subject: [Puppet Users] Re: [Roles/Profiles] when a technology module doesn't
already exist - seeking opinions
ALERT: This message originated outside of Aon's network. BE CAUTIOUS before
clicking any link or attachment.
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, without having to add
'profile::' at the beginning of every parameter.
You seem to be making things more complicated by using `contains` and those
Refresh arrows though. Why not just use `include`?
On Monday, June 8, 2020 at 5:26:56 PM UTC-4, Alan Evans wrote:
While _most_ things I want to manage via Puppet have modules on the forge that
are well maintained, tested and highly flexible. Sometimes though, I find that
there is something that my organizations uses that is just not common enough to
have a module on the forge.
In roles/profiles we consider things to be layered, with Roles at the top and
technology specific modules at the bottom. Profiles are our place to control
the behavior of technology specific modules and add any missing functionality
or business logic.
How do you deal with technologies that do not have corresponding modules on the
forge?
A) Write technology module and profile?
Pros:
- follows established practice
- most flexible
Cons:
- extra work
- possible duplication of effort
class foo ($param1, $param2, ... $paramN) {
contain foo::install
contain foo::config
contain foo::service
Class['foo::install'] -> Class['foo::config'] -> Class['foo::service']
}
class profile::foo ($param1 = 'my_default', $param2 = 'other_default', ...
$paramN) {
foo {
param1 => $param1,
param2 => $param2,
...
paramN = $paramN,
}
}
B) Put it all in a profile?
Pros:
- less work
- probably still flexible since you control the whole thing
Cons:
- does not match established practices
class profile::foo ($param1 = 'my_default', $param2 = 'other_default', ...
$paramN) {
contain profile::foo::install
contain profile::foo::config
contain profile::foo::service
Class['profile::foo::install'] -> Class['profile::foo::config'] ->
Class['profile::foo::service']
}
How have you handled this scenario in the past?
Thank you,
-Alan
--
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<mailto:puppet-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7181b554-99b5-4e64-80f2-90a7e1e12b76o%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/7181b554-99b5-4e64-80f2-90a7e1e12b76o%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/SN4P170MB0064BBC1522F30AB3838105DFA820%40SN4P170MB0064.NAMP170.PROD.OUTLOOK.COM.
