how do you name and group your data in hiera?

[Robert]

Hi List,

I'm on the verge of refactoring all our modules to the roles&profile 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

[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: '%sysadmin        ALL=(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: '%infrastructure        ALL=(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.

[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

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