Hiera lookup function doesnt fail if attr isnt found

111 views
Skip to first unread message

Joao Morais

unread,
Sep 18, 2015, 5:36:32 PM9/18/15
to puppet...@googlegroups.com

Hello list. I am using the hiera() lookup function in order to query
some few attributes from a http backend. Something like this:

common.yaml
---
...
class::attr: "%{hiera('other::attr')}"

This works very well if other::attr is defined, but an empty string is
returned in the lookup above if the other::attr isn't found. The hiera()
function on the manifest fails the compilation if I do the same query,
which is what I'd expect from the lookup above.

Is there a way to enforce the declaration of the other::attr when using
hiera() lookup function inside the hieradata?

Julian Meier

unread,
Sep 19, 2015, 8:39:07 AM9/19/15
to puppet...@googlegroups.com
Hi

Can't you just set a fallback or default value in the manifest?

Example:
`$attr = hiera('other::attr','fallback')`

http://docs.puppetlabs.com/hiera/1/puppet.html#hiera-lookup-functions

Julian
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55FC83C6.7080007%40joaomorais.com.br.
> For more options, visit https://groups.google.com/d/optout.

Joao Morais

unread,
Sep 19, 2015, 2:57:39 PM9/19/15
to puppet...@googlegroups.com
Em 19/09/15 09:38, Julian Meier escreveu:
> On 18 Sep 2015, at 23:36, Joao Morais <l...@joaomorais.com.br> wrote:
>>
>> Hello list. I am using the hiera() lookup function in order to
>> query some few attributes from a http backend. Something like this:
>>
>> common.yaml
>> ---
>> ...
>> class::attr: "%{hiera('other::attr')}"
>>
>> This works very well if other::attr is defined, but an empty
>> string is returned in the lookup above if the other::attr isn't
>> found. The hiera() function on the manifest fails the compilation
>> if I do the same query, which is what I'd expect from the lookup
>> above.
>>
>> Is there a way to enforce the declaration of the other::attr when
>> using hiera() lookup function inside the hieradata?
>
> Hi
>
> Can't you just set a fallback or default value in the manifest?
>
> Example: `$attr = hiera('other::attr','fallback')`
>
> http://docs.puppetlabs.com/hiera/1/puppet.html#hiera-lookup-functions

Hi, unfortunately this doesn't solve the problem I am facing: the user
_need_ to fill the "other::attr" data in the http backend or the catalog
compilation should fail. A default or blank value in my scenario means
wrong configuration which should't be applied. The compilation failing
does happen with hiera() inside manifests and I was expecting a way to
mimic this same behavior with hiera() inside hieradata.


Francois Lafont

unread,
Sep 19, 2015, 6:18:45 PM9/19/15
to puppet...@googlegroups.com
Hi,

On 19/09/2015 20:57, Joao Morais wrote:

> Hi, unfortunately this doesn't solve the problem I am facing: the user _need_ to
> fill the "other::attr" data in the http backend or the catalog compilation should
> fail. A default or blank value in my scenario means wrong configuration which
> should't be applied. The compilation failing does happen with hiera() inside manifests
> and I was expecting a way to mimic this same behavior with hiera() inside hieradata.

Maybe I'm wrong but, according to me, you should make a ticket because
your request is completely well-founded. ;)

To create a tiket => https://tickets.puppetlabs.com/secure/Dashboard.jspa

Regards.

François Lafont

jcbollinger

unread,
Sep 21, 2015, 9:10:25 AM9/21/15
to Puppet Users


On Friday, September 18, 2015 at 4:36:32 PM UTC-5, Joao Morais wrote:

Hello list. I am using the hiera() lookup function in order to query
some few attributes from a http backend. Something like this:

    common.yaml
    ---
    ...
    class::attr: "%{hiera('other::attr')}"

This works very well if other::attr is defined, but an empty string is
returned in the lookup above if the other::attr isn't found. The hiera()
function on the manifest fails the compilation if I do the same query,
which is what I'd expect from the lookup above.


You have a misconception, albeit an understandable one: the Puppet function hiera() is not the same as the Hiera interpolation function of the same name. The two perform very similar work, but there is no inherent reason to suppose that they must operate identically.  Their interfaces are not even quite the same (at least as far as their documentation says), for the Puppet function accepts up to three arguments, whereas the Hiera function documents only one.

 

Is there a way to enforce the declaration of the other::attr when using
hiera() lookup function inside the hieradata?



No such mechanism is documented.  You could file a feature request, but inasmuch as there may be sites that knowingly or unknowingly depend on the current behavior, I judge it unlikely that such a feature request would be accepted.  Perhaps PL would be more receptive if you structured the request as an extension rather than as a behavior change -- an alternative lookup function, for example, or an additional argument to the existing one.

For now, perhaps you could instead put a throwaway call to the Puppet hiera() function in an appropriate manifest, so as to force compilation failure there in the event that the wanted key is not defined.


John

Henrik Lindberg

unread,
Sep 21, 2015, 10:49:16 AM9/21/15
to puppet...@googlegroups.com
John is correct, there is nothing that states that interpolation should
fail if looked up value does not exist. It will get nil/undef which
translates into an empty string.

> For now, perhaps you could instead put a throwaway call to the Puppet
> hiera() function in an appropriate manifest, so as to force compilation
> failure /there/ in the event that the wanted key is not defined.
>

If you are using 3.x with future parser or 4.x other alternatives are
available. You can use the lookup() function instead of hiera() as it
supports validating the result against a type which could check that the
returned value has a particular pattern (i.e. non empty result from the
interpolation).

That also works for automatic data binding by declaring the type of the
parameter when using 3.x future parser or 4.x.

Otherwise, John's suggestion with an extra lookup of the interpolated
key would be a decent workaround in getting an assertion in place.

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

Reply all
Reply to author
Forward
0 new messages