This also depends if your requirement is only restricting users access to data. If thats all you need then to me this is falls more into what tool you use to store and edit your data, rather than the one you use to look it up, you might be able to use a hiera backend more advanced than the simple YAML one that uses something that has the concept of users and ACL's, maybe something like using hiera-http to talk to CouchDB and ensure that CouchDB permissions are locked down or one of the various database backends and store your data in something that allows granular access.
If however you also need to change the lookup strategy, hierarchy, data source...etc from Puppet depending on what is being configured, then Jerakia would be a solution. Craig On Thu, Feb 4, 2016 at 9:27 AM, Gerhardus Geldenhuis <gerhardus.geldenh...@gmail.com> wrote: > Hi Stefan, > It is a fairly common problem and until recently there has not been a very > elegant solution. Have a look at http://jerakia.io/ which is a drop in > replacement for Hiera. Its used in production by a Swiss bank and some other > places so even though it is fairly new is more than up to the task. Jerakia > offers an elegant solution to your silo problem and there is some examples > and documentation on the website to get you started. > > Regards > > > On Tuesday, 2 February 2016 22:40:12 UTC, Stefan Schulte wrote: >> >> Hello everyone, >> >> I am currently working in a Linux team that decided to use Puppet as a >> configuration management tool and we developed a couple of own modules, >> use a lot from the forge and we keep hiera data in a separate git >> repository (tools: r10k+controlrepo, one separate hiera repo not managed >> by r10k, gitlabs server to manage all git repos) >> >> The IT department is quite big and has different silos (e.g VMWare team, >> Linux team, Backup team, Storage team, etc) but we (meaning the linux >> team) want to use puppet to replace workflows that beforehand went >> through different departments, e.g. to configure backup for a new >> machine, the backup team had to create a node in their backup tool and >> than give us the necessary input to generate the correct configuration >> file on the new server. >> >> Ideally I would like them to manage the data in hiera the same way as we >> do, so they can leverage the hierarchy to define defaults on a subnet >> level, host level, etc. but on the otherhand access to the single hiera >> repo would allow them to basically reconfigure everything on a server >> (like adding data for the sudo module to add custom sudo rules). >> >> Even though this would be tracked through git logs, a lot of my >> collegues are not comfortable with that (and might even be against >> internal regulations) so I am wondering how you manage the fact when a >> lot of different teams with different knowledge about puppet, yaml, and >> git should contribute to hiera but should only manage stuff they care >> about/are responsible for. >> >> - Stefan >> > -- > 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/1d9fb756-cdfe-468f-b0fa-4b7a90a81e2a%40googlegroups.com. > > 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/CACxdKhHWMEwekPk2SAM2hgVjtp0dBjvZhRW5Fm98TiPVAr38Lw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
