RE: [Puppet Users] Re: [Roles/Profiles] when a technology module doesn't already exist - seeking opinions

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

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

[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!

-- 
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/49b77955-03f5-4d52-aa41-a0aa203d879fo%40googlegroups.com.

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

[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

-- 
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/757357f3-c5a7-4934-8a28-9dcb25795c0fo%40googlegroups.com.

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

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

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7181b554-99b5-4e64-80f2-90a7e1e12b76o%40googlegroups.com.