[Roles/Profiles] when a technology module doesn't already exist - seeking opinions

[Alan Evans]

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

[A Manzer]

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`?

[Ramin K]

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 optional. Either you need to manage that
complexity or you don't.

Ramin

On 6/8/2020 2:26 PM, 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
>
> |
> classfoo ($param1,$param2,...$paramN){
>   contain foo::install
>   contain foo::config
>   contain foo::service
> Class['foo::install']->Class['foo::config']->Class['foo::service']
> }
>
>
> classprofile::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
>
> |
> |
> classprofile::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...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/4e5e1a58-4d1e-4700-b3db-fd242567488bo%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/4e5e1a58-4d1e-4700-b3db-fd242567488bo%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Alan Evans]

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.  So I guess that alone should have been my answer.

 

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.

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.

 

You seem to be making things more complicated by using `contains` and those Refresh arrows though.  Why not just use `include`?

Honestly I was just putting a few w things in my example class to flesh it out but I used contain because I use the Puppetlabs NTP module as my template or benchmark.  The subtleties of `include` vs `contain` evade me.

Thanks for your input,

-Alan

[Alan Evans]

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 

[A Manzer]

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 wrap it and to put profile:: keys in hiera.  But one of the first principals of the Puppet Style Guide is readability, and I think most of the time it's more readable without the "profile::" prefixes.

Honestly I was just putting a few w things in my example class to flesh it out but I used contain because I use the Puppetlabs NTP module as my template or benchmark.  The subtleties of `include` vs `contain` evade me.

 

They do for me as well.  But, I think because you don't know why you need `contain`, that means you don't actually need it. ;-)

From what I recall, it's from early Puppet days when resources somehow "leaked" out of their class?  And that was bad?  So the "anchor pattern" was invented, and then that was formalized into `contain`.  I think for 99% of cases, `include` is sufficient. 

You should also be able to replace your resource chaining arrows with proper use of `notify` and `subscribe` parameters in resources.

Happy Puppeting!

[Ramin K]

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 cases.

class profile::chrony {
# ptp refclocks only provided by Azure (so far)
# and only supported on rhel 7 or better.
# cloud_vendor is specified in manifests/site.pp
if $facts['os']['family'] == 'Redhat' and
versioncmp($facts['os']['release']['major'], '7') >= 0 and
$::cloud_vendor == 'azure' {
$refclocks = ['PHC /dev/ptp0 poll 3 dpoll -2 offset 0']
} else {
$refclocks = []
}

class { 'chrony':
refclocks => $refclocks,
}
}

Same system we have a number of modules that don't need any logic. We
apply it all in profile::std because that a convenient place to group it.

# standard linux profile for all linux servers
class profile::std::linux {

include bash
include cron
include firewalld
include git
include sendmail
include ssh

etc etc

The point is you get to pick when you bring profiles in.

Ramin

> --
> 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...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/puppet-users/84aec7a5-3b03-49f2-8dba-99a946cfedf1o%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/84aec7a5-3b03-49f2-8dba-99a946cfedf1o%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Kurt Werner]

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...@googlegroups.com <puppet...@googlegroups.com> On Behalf Of A Manzer
Sent: Tuesday, June 9, 2020 7:23 AM
To: Puppet Users <puppet...@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.

 

--

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...@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.