I'm wondering if anyone has this unique use case.
We're going to experiment by giving our ops team their own hieradata
repository, and keep our internal repository separate.
(If you're curious, we'll be giving them control over the %{::hostname}
tier, and we'll keep common / roles / project layers in the hierarchy
tied at the 'dev' hieradata).
The reason we're trying this is to experiment with different controls over
different repositories. Ops owns one, so they don't have to have the rigor
of feature branches and pull requests and the rest of the SDLC that comes
with our dynamic environment testing approach.
*Ultimately: *I want this:
:backends:
- opsyaml
- yaml
:yaml:
:datadir: /etc/puppetlabs/puppet/hieradata/%{::environment}
:opsyaml:
:datadir: /etc/puppetlabs/puppet/hostdata
:extension: yaml
but am limited because of this
code:
https://github.com/puppetlabs/hiera/blob/60f9d2d4b8b36e6dd47c3713dd64dc793b9745c0/lib/hiera/config.rb#L74-L82
*Possible solutions:*
1) create our own simple backend
2) symlink hostyaml_backend.rb to yaml_backend.rb
3) use eyaml, and yaml backends, just because it's easy .. :)
Does anyone have the same requirements? What worked for you?
--
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/73086f39-fbe9-4a51-bdde-e562de88efe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
