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 <[email protected]> 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 [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 > <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 [email protected]. 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.
