Puppet users - May 2013 - hiera - anything better than empty string?

Hi,

starting to use hiera in earnest now (still on puppet 2.6 but planning an
upgrade to 3.x this summer).

the heirarchy looks for fqdn, then network_eth0, then
''default''.

Some of our subnets don''t want to set http_proxy environment variables,
the
rest do.

so default.json has a ''http_proxy_url'' key in it, but I want
to exclude it
for 10.9.8.7.

Is there a ''special'' hiera value I can set in 10.9.8.7.json to
stop the
search falling down into default.json ?

At the minute we''ve set an empty string, but then templates etc. need
to be
littered with

if ($url_from_hiera != "") {
  do_stuff()
}

which feels like the sort of ''magic variable'' that will bite
future me in
the ass in around 6 months.

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, May 15, 2013 6:29:14 AM UTC-5, Dick Davies
wrote:
>
> Hi, 
>
> starting to use hiera in earnest now (still on puppet 2.6 but planning an 
> upgrade to 3.x this summer).
>
> the heirarchy looks for fqdn, then network_eth0, then
''default''.
>
> Some of our subnets don''t want to set http_proxy environment
variables,
> the rest do.
>
> so default.json has a ''http_proxy_url'' key in it, but I
want to exclude it
> for 10.9.8.7.
>
> Is there a ''special'' hiera value I can set in
10.9.8.7.json to stop the
> search falling down into default.json ?
>

Yes, and no.  ANY value you set for that key in 10.9.8.7.json will prevent 
the search from consulting the next hierarchy level.  But it will cause the 
lookup to return the given value.  As far as I know, there is no value that 
represents "no value".

 
>
> At the minute we''ve set an empty string, but then templates etc.
need to
> be littered with
>
> if ($url_from_hiera != "") {
>   do_stuff()
> }
>
> which feels like the sort of ''magic variable'' that will
bite future me in
> the ass in around 6 months.
>
>
So, what do you envision hiera returning instead?  undef?  How would that 
make things better for you?  Wouldn''t you still need similar
conditional
logic in all the same places?

I don''t see the magic variable problem in this case, in that the empty 
string is actually a pretty good representation of the meaning you want to 
convey.  You might even find that setting the http_proxy environment 
variable to an empty string has the desired effect (of not trying to use a 
proxy), though that''s speculative on my part.  If that did work then
the
empty string wouldn''t be magic at all.


John

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On 15 May 2013 15:24, jcbollinger <John.Bollinger@stjude.org> wrote:
>
>
> On Wednesday, May 15, 2013 6:29:14 AM UTC-5, Dick Davies wrote:
>>
>>
>> At the minute we''ve set an empty string, but then templates
etc. need to
>> be littered with
>>
>> if ($url_from_hiera != "") {
>>   do_stuff()
>> }
>>
>> which feels like the sort of ''magic variable'' that
will bite future me in
>> the ass in around 6 months.
>>
>>
>
> So, what do you envision hiera returning instead?  undef?  How would that
> make things better for you?  Wouldn''t you still need similar
conditional
> logic in all the same places?
>
>
I can get a bit closer to the ideal if I set the value as : false
- then the templates look like this (the $yum_proxy_url gets unpacked out
of hiera
up in the module):

<%- if yum_proxy_url != false %>
# use proxy
proxy=<%=yum_proxy_url %>
<% end -%>

which is a bit more readable. Not really clear why the : != false part is
required, but
feels cleaner to me.

And no, annoyingly

proxy
breaks yum :)


I don''t see the magic variable problem in this case, in that the
empty
> string is actually a pretty good representation of the meaning you want to
> convey.  You might even find that setting the http_proxy environment
> variable to an empty string has the desired effect (of not trying to use a
> proxy), though that''s speculative on my part.  If that did work
then the
> empty string wouldn''t be magic at all.
>
-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, May 15, 2013 10:45:19 AM UTC-5, Dick Davies
wrote:
>
> On 15 May 2013 15:24, jcbollinger <John.Bo...@stjude.org
<javascript:>>wrote:
>
>>
>>
>> On Wednesday, May 15, 2013 6:29:14 AM UTC-5, Dick Davies wrote:
>>>
>>>
>>> At the minute we''ve set an empty string, but then
templates etc. need to
>>> be littered with
>>>
>>> if ($url_from_hiera != "") {
>>>   do_stuff()
>>> }
>>>
>>> which feels like the sort of ''magic variable''
that will bite future me
>>> in the ass in around 6 months.
>>>
>>>
>>
>> So, what do you envision hiera returning instead?  undef?  How would
that
>> make things better for you?  Wouldn''t you still need similar
conditional
>> logic in all the same places?
>>
>>
> I can get a bit closer to the ideal if I set the value as : false 
> - then the templates look like this (the $yum_proxy_url gets unpacked out 
> of hiera
> up in the module):
>
> <%- if yum_proxy_url != false %>
> # use proxy
> proxy=<%=yum_proxy_url %>
> <% end -%>
>  
> which is a bit more readable. Not really clear why the : != false part is 
> required, but
> feels cleaner to me.
>
>
In other words, yes, you do need all the same logic in all the same 
places.  In that case, your only real option is to choose the special value 
you like best.  Personally, I find the empty string very appropriate, and 
whereas there could conceivably be a machine named "false", but there 
cannot be one named "".  Still, it''s a matter of taste.

 
> And no, annoyingly 
>
> proxy>
> breaks yum :)
>
>
Bummer.


John
 

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On 15 May 2013 19:33, jcbollinger <John.Bollinger@stjude.org> wrote:
>
>
> On Wednesday, May 15, 2013 10:45:19 AM UTC-5, Dick Davies wrote:
>
>>
>> <%- if yum_proxy_url != false %>
>> # use proxy
>> proxy=<%=yum_proxy_url %>
>> <% end -%>
>>
>> which is a bit more readable. Not really clear why the : != false part
is
>> required, but
>> feels cleaner to me.
>>
>>
>
> In other words, yes, you do need all the same logic in all the same
> places.  In that case, your only real option is to choose the special value
> you like best.  Personally, I find the empty string very appropriate, and
> whereas there could conceivably be a machine named "false", but
there
> cannot be one named "".  Still, it''s a matter of taste.
>
Absolutely - see your point - it looks to me like the template is treating
literal false (not "false")
as a string rather than a boolean.
I might be wrong but my reading is that hiera can return booleans as well
as strings,
so maybe it''s a template thing? Anyway, spent enough time on this for
now -
cheers.

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.