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 On Mon, May 7, 2018 at 3:25 PM Thomas Müller <tho...@chaschperli.ch> wrote: > 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 > <https://groups.google.com/d/msgid/puppet-users/6b2b028c-d20a-4aa3-a7c1-37f779e4eece%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CANwwCtzZ1Au4wVnHwGhZUvcBdcuG-7zxVAA-1ypBRnnNewUftA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
