Re: [Puppet Users] Re: how do you name and group your data in hiera?

[Robert]

Hi Rob,

thank for the feedback.

So you also merge values accross different Hiera tiers. I will probably
also use this in my modules and there will be cases where this will be the
right solution for what I want to achieve.

But merging values from the _same tier_ seems not be possible then. Like
profiles::*::certs or whatever. So it seems that I really do have to take
care of the right values of profiles::java::certs for every component
module that I include, since I can't use the merged values from
profiles::tomcat::certs + profiles::apache::certs in java::certs
(everything is just an example, but you probably get the point) - without
extra hacking of course :)

Best
Rp





On Fri, Jan 27, 2017 at 1:21 PM, Rob Nelson  wrote:

> I apparently use a different sudo module than you do (saz/sudo), but have
> the same concerns. We have a general sudoers setup that gets applied to all
> nodes and additional config for certain roles. We manage this in the base
> profile class using iteration (note: I don't think I guard against
> `$sudo_confs` actually being undef, which may cause catalog compilation
> failures if it occurred):
>
> class profile::base::linux (
>   $sudo_confs = undef,
> ) {
>   ...
>   # Sudo setup
>   include ::sudo
>   $sudo_confs.each |$group, $config| {
> sudo::conf{ $group:
>   * => $config,
> }
>   }
> }
>
> In hiera/global.yaml:
>
> ---
> lookup_options:
>   profile::base::linux::sudo_confs:
> merge: deep
> profile::base::linux::sudo_confs:
>   sysadmin:
> priority: 10
> content: '%sysadminALL=(ALL)   ALL'
>
> The `lookup_options` ensures that the content is found and merged across
> hiera tiers rather than overwriting at each level. Then we can do things
> like this in hiera/puppet_role/build.yaml, for a 'build' role:
>
> ---
> profile::base::linux::sudo_confs:
>   infrastructure:
> priority: 15
> content: '%infrastructureALL=(ALL)   ALL'
>
> On almost every node, profile::base::linux::sudo_confs has a single key
> 'sysadmin'. On nodes with the `puppet_role` fact set to `build`, there's a
> second key, `infrastructure`, and thus a second sudo configuration is
> applied on those nodes. You can also look at the `knockout_prefix` key for
> `lookup_options` if you decide you need to eliminate some keys on certain
> nodes.
>
>
> On Friday, January 27, 2017 at 3:47:58 AM UTC-5, Robert wrote:
>>
>> Hi List,
>>
>> I'm on the verge of refactoring all our modules to the roles
>> workflow with r10k etc. and the stuff is taking shape - thanks for all the
>> help so far! - and the only thing I'm still not very convenient with is the
>> naming/grouping of data put into Hiera and using that data in the profiles.
>> Let me explain.
>> Somehow I always wanted to do something like this:
>>
>> ---
>> profile::tomcat::sudoers:
>>   tomcatadmingroup:
>> - systemctl start tomcat.service
>> - systemctl stop tomcat.service
>> profile::apache::sudoers
>>   apacheadmingroup:
>> - systemctl start httpd.service
>> - systemctl stop httpd.service
>>
>> since if I classify a node with the Tomcat module, I'd like the tomcat
>> admins to be able to start and stop the service. I think this resource
>> belongs to the profile::tomcat. This way, I'd use:
>> profiles::tomcat {
>> ...
>>   class { "sudoers":
>> sudoers => $::profiles::tomcat::sudoers
>>   }
>> }
>>
>> profiles::apache {
>> ...
>>   class { "sudoers":
>> sudoers =>$::profiles::apache::sudoers
>>   }
>> }
>>
>> This is (imho) way nicer than trying to remember to extend all these
>> resources every time I need something new, like "Tomcat needs a port, a
>> user, a certificate so let's extend profile::firewall with the port,
>> profile::certs with the cert. Ah crap I forgot the java version in
>> profiles::java at the bottom of the yaml file!".
>>
>> But this solution obviously doesn't work if a node has both the tomcat
>> and apache modules because of the multiple resource-like class declarations
>> of the same class.
>>
>> Another example would be that if the tomcat module is assigned to a node,
>> then the tomcat-admins should be able to login via ssh. And the same goes
>> for other admin groups. Assuming this:
>>
>> profiles::tomcat::pamd:
>>   - 'tomcatadmins'
>> profiles::oracle::pamd:
>>   - 'oracleadmins'
>>
>> the final variable used in the pamd class should be ["tomcatadmins",
>> "oracleadmins"] but I can't really get this array in the pamd profile with
>> hiera (or can I?).
>>
>> Maybe some merging would be possible but I can't simply look up
>> "profile::*::pamd" and merge the results.
>> Afaik hiera_array is only possible with data on different Hiera levels.
>> I could use subclasses like ::sudoers::tomcat, ::sudoers::apache...
>> ::pamd::oracle ::pamd::tomcat etc. but that'd be complex and time-consuming.
>>
>> How could I (meaningfully) use "include ::classname" everywhere without
>> doing something weird?
>> How do you group your data?
>>
>> Best

[Puppet Users] Re: how do you name and group your data in hiera?

[Rob Nelson]

I apparently use a different sudo module than you do (saz/sudo), but have 
the same concerns. We have a general sudoers setup that gets applied to all 
nodes and additional config for certain roles. We manage this in the base 
profile class using iteration (note: I don't think I guard against 
`$sudo_confs` actually being undef, which may cause catalog compilation 
failures if it occurred):

class profile::base::linux (
  $sudo_confs = undef,
) {
  ... 
  # Sudo setup
  include ::sudo
  $sudo_confs.each |$group, $config| {
sudo::conf{ $group:
  * => $config,
}
  }
}

In hiera/global.yaml:

---
lookup_options:
  profile::base::linux::sudo_confs:
merge: deep
profile::base::linux::sudo_confs:
  sysadmin:
priority: 10
content: '%sysadminALL=(ALL)   ALL'

The `lookup_options` ensures that the content is found and merged across 
hiera tiers rather than overwriting at each level. Then we can do things 
like this in hiera/puppet_role/build.yaml, for a 'build' role:

---
profile::base::linux::sudo_confs:
  infrastructure:
priority: 15
content: '%infrastructureALL=(ALL)   ALL'

On almost every node, profile::base::linux::sudo_confs has a single key 
'sysadmin'. On nodes with the `puppet_role` fact set to `build`, there's a 
second key, `infrastructure`, and thus a second sudo configuration is 
applied on those nodes. You can also look at the `knockout_prefix` key for 
`lookup_options` if you decide you need to eliminate some keys on certain 
nodes.

On Friday, January 27, 2017 at 3:47:58 AM UTC-5, Robert wrote:
>
> Hi List,
>
> I'm on the verge of refactoring all our modules to the roles 
> workflow with r10k etc. and the stuff is taking shape - thanks for all the 
> help so far! - and the only thing I'm still not very convenient with is the 
> naming/grouping of data put into Hiera and using that data in the profiles. 
> Let me explain.
> Somehow I always wanted to do something like this:
>
> ---
> profile::tomcat::sudoers:
>   tomcatadmingroup:
> - systemctl start tomcat.service
> - systemctl stop tomcat.service
> profile::apache::sudoers
>   apacheadmingroup:
> - systemctl start httpd.service
> - systemctl stop httpd.service
>
> since if I classify a node with the Tomcat module, I'd like the tomcat 
> admins to be able to start and stop the service. I think this resource 
> belongs to the profile::tomcat. This way, I'd use: 
> profiles::tomcat {
> ...
>   class { "sudoers":
> sudoers => $::profiles::tomcat::sudoers
>   }
> }
>
> profiles::apache {
> ...
>   class { "sudoers":
> sudoers =>$::profiles::apache::sudoers
>   }
> }
>
> This is (imho) way nicer than trying to remember to extend all these 
> resources every time I need something new, like "Tomcat needs a port, a 
> user, a certificate so let's extend profile::firewall with the port, 
> profile::certs with the cert. Ah crap I forgot the java version in 
> profiles::java at the bottom of the yaml file!".
>
> But this solution obviously doesn't work if a node has both the tomcat and 
> apache modules because of the multiple resource-like class declarations of 
> the same class.
>
> Another example would be that if the tomcat module is assigned to a node, 
> then the tomcat-admins should be able to login via ssh. And the same goes 
> for other admin groups. Assuming this:
>
> profiles::tomcat::pamd: 
>   - 'tomcatadmins'
> profiles::oracle::pamd: 
>   - 'oracleadmins'
>
> the final variable used in the pamd class should be ["tomcatadmins", 
> "oracleadmins"] but I can't really get this array in the pamd profile with 
> hiera (or can I?).
>
> Maybe some merging would be possible but I can't simply look up 
> "profile::*::pamd" and merge the results.
> Afaik hiera_array is only possible with data on different Hiera levels.
> I could use subclasses like ::sudoers::tomcat, ::sudoers::apache... 
> ::pamd::oracle ::pamd::tomcat etc. but that'd be complex and time-consuming.
>
> How could I (meaningfully) use "include ::classname" everywhere without 
> doing something weird? 
> How do you group your data?
>
> Best
> Rp
>
>
>

-- 
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/8a068b3a-22aa-493f-8ec7-1c5396bfea95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.