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 Am Sonntag, 6. Mai 2018 21:26:55 UTC+2 schrieb 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 > > > -- 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 [email protected]. 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.
