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 puppet-users+unsubscr...@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.
