structured/normal facts in a string behave different

30 views
Skip to first unread message

Johan De Wit

unread,
Mar 3, 2015, 5:18:58 PM3/3/15
to puppet...@googlegroups.com
Hi,

Playing with structured facts, I noticed some starnge behaviour.

If one need to access eg the fact $os['release']['full'], you get the
full hash when. You need to embed the fact like
${os['release']['full']} to get the exact value of the hash.

Normal facts dont have this issue. (they dont have indexes which can eb
ignored)

Well, one should always use the ${variable} in a string, but if not,
this should at least give a big warning, if not an error.

Some tests showing this result ....

https://gist.github.com/witjoh/c828ebb372621d09b873

Could someone verify this on there systems ?

Running PE3.7.2, with future parse/structured facts enabled ....

Just to be sure it is not something mis-configured in my setup

--
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer (805008667232363)
Puppet Certified Professional 2013/2014 (PCP0000006)
Puppet Certified Intstructor
blog : http://johan.koewacht.net/
_________________________________________________________

Open-Future Phone +32 (0)2/255 70 70
Zavelstraat 72 Fax +32 (0)2/255 70 71
3071 KORTENBERG Mobile +32 (0)474/42 40 73
BELGIUM http://www.open-future.be
_________________________________________________________


Next Events:
Puppet Fundamentals | http://www.open-future.be/puppet-fundamentals-training-16th-till-18th-march
Puppet Architect | http://www.open-future.be/puppet-architect-training-19th-till-20th-march
Puppet Practitioner | http://www.open-future.be/puppet-practitioner-training-14th-till-16th-april
Linux Training | http://www.open-future.be/linux-training-20th-till-24th-april
Bacula Administrator 1 | http://www.open-future.be/bacula-administrator-i-training-28th-till-30th-april
Zabbix Certified Specialist | http://www.open-future.be/zabbix-certified-specialist-training-4th-till-6th-may
Zabbix Certified Professional | http://www.open-future.be/zabbix-certified-professional-training-7th-till-8th-may
Subscribe to our newsletter | http://eepurl.com/BUG8H

Henrik Lindberg

unread,
Mar 3, 2015, 8:19:30 PM3/3/15
to puppet...@googlegroups.com
On 2015-03-03 23:18, Johan De Wit wrote:
> Hi,
>
> Playing with structured facts, I noticed some starnge behaviour.
>
> If one need to access eg the fact $os['release']['full'], you get the
> full hash when. You need to embed the fact like
> ${os['release']['full']} to get the exact value of the hash.
>
> Normal facts dont have this issue. (they dont have indexes which can eb
> ignored)
>
> Well, one should always use the ${variable} in a string, but if not,
> this should at least give a big warning, if not an error.
>
> Some tests showing this result ....
>
> https://gist.github.com/witjoh/c828ebb372621d09b873
>
> Could someone verify this on there systems ?
>
> Running PE3.7.2, with future parse/structured facts enabled ....
>
> Just to be sure it is not something mis-configured in my setup
>

Interpolation using the short form e.g. "hello $name, how are you",
only supports interpolation of a variable, not an expression involving
the variable, thus:

$name = {firstname => fred, lastname => flintstone}
"hello $name[lastname]"

will render:

"hello {firstname => fred, lastname => flintstone}[lastname]"

since the interpolation of $name interpolates the entire hash, it then
continues with the [lastname] as text!

This is exactly what happened in your gist.

And you are correct that you must use the long form interpolation since
you are interpolating an expression.

All details about string interpolation in future parser / puppet 4.0.0
are found here:
https://github.com/puppetlabs/puppet-specifications/blob/master/language/expressions.md#string-interpolation


Hope that helps
Regards
- henrik



--

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

Johan De Wit

unread,
Mar 4, 2015, 2:59:42 AM3/4/15
to puppet...@googlegroups.com
Thanks Henrik,

it does make a bit more sense :)

Reading the docs over again :)
Reply all
Reply to author
Forward
0 new messages