fact parsing was a problem with a template not the hiera code.
The only way I get this working is if I do a lookup in a profile manifest
of the main hash, then reference that variable back in hiera.
This seems wrong, and coupled, and flakey, which is why it's listed as a
bad practice on the puppetlabs documentation.
However, apparently we did this another time trying to solve the same
problem.
In software, seeming to be forced into an anti-pattern twice would indicate
there is a better design. If anyone has any thoughts here - we want to
hear it! Either that or we need a different hiera function for this.
On Tuesday, 22 March 2016 16:33:57 UTC-6, Brett Swift wrote:
>
> Well that's what I've been going off, but I haven't figured out the right
> syntax.
>
> I've tried escaping the nested single quotes.. no luck.
>
> One strange thing right now is I can't even interpolate facts.
>
> ---
> test: "%{::hostname}"
>
> is failing on a lookup. hmm.
>
>
>
> On Tuesday, 22 March 2016 16:00:12 UTC-6, Carthik Sharma wrote:
>>
>> This might help:
>>
>> https://docs.puppetlabs.com/hiera/3.1/variables.html#interpolating-hash-or-array-elements
>>
>> Thanks.
>>
>> On Tue, Mar 22, 2016 at 2:14 PM, Brett Swift <[email protected]> wrote:
>>
>>> This is a bit nutty, but hopefully there's a way to do this.
>>>
>>> So far I have only been able to get the parent hash, not the nested one.
>>>
>>>
>>> The reason I don't want to do this in a manifest, is because I'd like
>>> to use pieces of this hash within hiera itself.
>>>
>>> This gist is what I'm trying to do:
>>> https://gist.github.com/brettswift/560af53d379e0d86730c
>>>
>>> pasted here:
>>> group_allocation:
>>> devcoreoeml030.matrix.sjrb.ad: smokestack
>>> devcorebrml030.matrix.sjrb.ad: smokestack
>>> devcoreesbl030.matrix.sjrb.ad: smokestack
>>> devcoreoeml091.matrix.sjrb.ad: the091
>>> devcorebrml091.matrix.sjrb.ad: the091
>>> devcoreesbl091.matrix.sjrb.ad: the091
>>> devcorepptl003.matrix.sjrb.ad: dev_master
>>> tstcorepptl003.matrix.sjrb.ad: tst_master
>>> devcorepptl918.matrix.sjrb.ad: brett_sandbox
>>> devcorepptl919.matrix.sjrb.ad: brett_sandbox
>>> groups:
>>> core030:
>>> data:
>>> tag: smokestack
>>> owner: bcornies
>>> the091:
>>> data:
>>> tag: brettstack
>>> owner: bswift
>>> brett_sandbox:
>>> data:
>>> tag: brett
>>> owner: bswift
>>> my_group_name: "%{hiera('group_allocation')}.%{::fqdn}"
>>> my_group: "%{hiera('groups[%{hiera('my_group_name')}]')}"
>>> #my_tag: ...
>>>
>>>
>>> My goal is to find access to the tag, owner, etc. This is a bit nutty
>>> as it's kind of relational data in hieradata, but we're hoping we can do
>>> this.
>>>
>>> Right now the two lookups at the bottom do not work. I can get the top
>>> level lookup, but beyond that - it's not working. Has someone done this? I
>>> can only seem to find examples to compare with this being done in a
>>> manifest file, not in a yaml file.
>>>
>>> --
>>> 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 [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/0695140c-1d59-4708-9e35-f6020bcf3345%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/puppet-users/0695140c-1d59-4708-9e35-f6020bcf3345%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/56954e39-0130-4f58-9164-5b38b73347e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
