Hiera brainstorming

[Robert]

Hi List,

I invite you to a bit of brain-workout ;) I couldn't figure this out on my own so far.

At our company we have a group of linux-admins who are responsible for the infrastructure (the hardware and the operating system) and we have application teams, like the database admins or a team for the backup software.

Some servers are only administered by the linux-admins, but in many cases, we'd like to  delegate them to one app-team. The OS settings always belong to the linux-admins, but e.g. Oracle itself is administered by the database team.

To achieve that, we have 9 levels of hierarchy in hiera atm. The ordered list of data sources is the following:

1. admin level: node yamls
   
2. admin level: role/stage (e.g. oracle/prod)
3. admin level: role (e.g. oracle)
4. admin level: common
   
   
5. $team level: node yamls
6. $team level: role/stage
7. $team level: role
8. $team level: common
   
   
9. default.yaml

If something is set on the levels 1-4, the teams can not override it, because that's how Hiera works (assuming proper lookup options of course). 

The team levels are actual git repositories of the given team; $team is a custom fact.

So if I specify "oracle" as the value of the $team custom fact on a given server, Hiera will look up keys/values from the oracle repository as the 5-8 levels. That does work, everything's fine.

And the problem: sometimes I'd like to have teams to control only a specific application, on a server which is already delegated to a team. E.g. the backup admins should be able to configure the backup software's agent on Oracle *and* webservers as well, but $team == oracle and $team == web on these servers already, of course. 

I might add the backup-team levels at 9-12 and move "default" to 13, but there won't be only one such "secondary" team. And 13 are already a LOT of hiera levels, not to mention even more...

Any ideas how to do this? The easiest way would be of course to give the backupteam access to every team-repository. Erm... no.

Then, maybe every $team repository could have a subdirectory for such secondary groups, e.g. the oracle/backup directory to which the backup team's access is restricted, so that they can't see or edit the oracle settings outside of this. But I can't do this with git afaik (with svn that'd work).

Any ideas, suggestions?

Best

Rp

[Thomas Müller]

Hi Robert

I personally think these are too many levels.

Instead introducing complexity by levels I would suggest you to implement a review process (like: pull-requests with mandatory reviews) to prevent disallowed settings to even hit production. This also will help you to share knowledge and give you better quality in the end.

- Thomas

[Robert]

Hi Thomas,

I appreciate your input. While these might be too many levels according to a specific metric, I don't think it's *that* much. I'd be uncomfortable with even more levels but not because it wouldn't work from a technical aspect. A hiera lookup from a data_hash backend is considered an inexpensive operation.

Regarding review process: we are not staffed 24/7 and I don't want to babysit the teams. They should know what they're doing with their stuff and there can be changes by these teams outside our office hours. While this is definitely a good point, I'd prefer something we have already. Not that I'm completely against any change to the setup - of course we evaluated reviews at the beginning, but I see our actual setup as an improvement over that, at least in our particular case.

Thanks,

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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6b2b028c-d20a-4aa3-a7c1-37f779e4eece%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Craig Dunn]

On Sun, May 6, 2018 at 9:26 PM, Robert <robp...@gmail.com> wrote:

And the problem: sometimes I'd like to have teams to control only a specific application, on a server which is already delegated to a team. E.g. the backup admins should be able to configure the backup software's agent on Oracle *and* webservers as well, but $team == oracle and $team == web on these servers already, of course. 

Have you looked at Jerakia? (disclaimer: I maintain it) You're requirements are almost identical to what lead to it's development in the first place and this use case isn't too dissimilar from the use case in the example here;  https://www.craigdunn.org/2015/09/solving-real-world-problems-with-jerakia/

With that you can have multiple lookups each with their own datasource / hierarchy but confine or exclude the lookups from the search based on a customizable criteria such as the team....etc.  So you could route lookup requests originating from the oracle module to an entirely different lookup and set of data but that lookup won't get used for other modules.... Sounds like it would probably solve your issue without having a giant hierarchy that get scanned for every single key.

Craig

--

Enviatics     |      Automation and Configuration Management

http://www.enviatics.com | @Enviatics | cr...@enviatics.com