Ah, I misunderstood Eric's response to Eli then. Well as long as the
location is the same regardless of edition and only varies by version (I.e.
$::puppetversion >= 4.5.0 or similar) it shouldn't muck things up too much.
On Tuesday, March 15, 2016, R.I.Pienaar wrote:
>
>
> On 15 Mar 2016, at 02:
> On 15 Mar 2016, at 02:13, Rob Nelson wrote:
>
> I've not seen a conflict with r10k, can you elaborate on that? Curious if I'm
> hitting it and not knowing it!
>
> However, I have seen it cause great confusion with modules like hunner/hiera
> or jlambert121/puppet that want to manage it, be
I've not seen a conflict with r10k, can you elaborate on that? Curious if
I'm hitting it and not knowing it!
However, I have seen it cause great confusion with modules like
hunner/hiera or jlambert121/puppet that want to manage it, because there's
an ugly set of possible locations depending on oss
As a result of some introspection around r10k workflows, I came to agree
with the statement in the title of HI-490: "the location of hiera.yaml in
puppet-agent is a mistake." The root of the problem is that the current
hiera.yaml is a mixture of global configuration (datadir location, merge
beh
