On 9 February 2015 at 20:12, Brett Swift wrote:
> 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.
We have a similar requirement whereby our infrastructure team
(hand
Yea I've tested a redis backend as an ENC but we haven't enabled it yet as
we'll likely ditch it for the console enc in 3.7.
The problem with Redis is lack of version control, which our Ops guys do
want. ( unless you did an http backend that served up a file system with
your yaml files.. er
gah, link is https://www.youtube.com/watch?v=7NBJAC10ato
On 2/9/15 12:37 PM, Ramin K wrote:
In the past I've used yaml for Ops and json for Dev. That worked
well and it was mostly automated scripts that we dropping files into a
different path.
While it's much more work you might consi
In the past I've used yaml for Ops and json for Dev. That worked well
and it was mostly automated scripts that we dropping files into a
different path.
While it's much more work you might consider Redis as a Hiera backend
coupled with an http user interface and api. I did some work around
a
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 / proje
