(inline)
On Tue, Feb 02, 2016 at 11:38:20PM +0100, 'Stefan Schulte' via Puppet Users
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)
Been there, but if you're managing one git repository with r10k why not manage
them all?
> 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).
Going into creative-uses-of-hiera land, and keeping in mind that different
teams can have different levels of access to individual git projects and
groups, you can use the puppet environment (or another variable) to
differentiate hiera levels. The git repos can be kept up to date with r10k. The
individual teams don't need access to the puppetmasters, you can use an
mcollective plugin or git commit hooks or some related solution to keep r10k
going.
:hierarchy:
- 'r10k/%{environment}/hieradata/datacenters/%{datacenter}
- 'r10k/%{environment}/hieradata/clusters/%{cluster}
I assume in this scenario your environments would be "backup", "storage", and
so on. Something broadly similar is working well enough for us, but to be
perfectly frank, getting your organization on the same page is going to be the
harder part of the task.
> 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.
You should re-read those internal regulations before you attempt to change your
puppetmaster internals.
> - 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/56B12FDC.8090801%40taunusstein.net.
> 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/20160204184451.GA12931%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
