Hi Spencer,
On 2013-16-09 3:39, Spencer Krum wrote:
Hello,
I am trying to follow ARM-9 and use the data in modules features
introduced in the 3.3 release. I am struggling to get many of the
features mentioned in ARM-9 working. I have a basic module here
https://github.com/pro-puppet/puppet-module-startrek, but when trying to
add an element to the hierarchy (see branch 'species') I'm hitting a
roadblock. I have copied in the binder_config.yaml file from ARM-9, even
without modifications, and I get the following error:
root@hiera-2:/etc/puppet# !pup
puppet apply modules/startrek/tests/init.pp
Error: syntax error on line 3, col 20: ` { 'name' => 'site',' on node
hiera-2.green.gah
Error: syntax error on line 3, col 20: ` { 'name' => 'site',' on node
hiera-2.green.gah
Can you share the binder_config.yaml? I could not see it in your
startrek module repository (it should not be there, so not surprising).
If anything I would like to see what it looks like to make sure a better
error message gets produced. The error you posted above is not
informative and should be handled better.
So I guess my immediate question is "is the binder_config.yaml snippet
in ARM-9 correct? is there an error in it somewhere?" and my larger
question is where are the full examples of how to do use this? I doubt
that all this code was developed without simple testing modules being
built alongside it to test features.
I did take a quick look at the ARM-9 text, and OMG, there are some text
conversion problems (googledoc to markdown) where several \ characters
are inserted in odd places. Will post a fix for that asap. There should
be no backslashes - so the text:
include: ['module-hiera:/\*', 'module:/\*::default'],
is wrong and should say:
include: ['module-hiera:/*', 'module:/*::default'],
will need to read through all of it carefully to find the typos.
Meanwhile, here is a sample that I used:
(I just noticed that I used /*/ in one place, don't think that is
required, it is a path so /* should work just as well).
binder_config.yaml:
---
version: 1
layers:
[{name: site, include: 'confdir-hiera:/'},
{name: modules, include: ['module-hiera:/*/', 'module:/*::default'] }
]
categories:
[['node', '${fqdn}'],
['environment', '${environment}'],
['osfamily', '${osfamily}'],
['common', 'true']
]
This style of yaml also works:
---
version: 1
layers:
- {name: site, include: 'confdir-hiera:/'}
- {name: modules, include: 'module-hiera:/*/', exclude:
'module-hiera:/bad/' }
categories:
- ['node', '$fqn']
- ['environment', '$environment']
- ['common', 'true']
Third, it says in ARM-9 that all lookups are performed using topscope.
Does that mean we no longer have access to variables set at local scope
when we do our lookup?
Yes, that is true. All bindings are made upfront before evaluation of
anything else takes place. Basically only facts are available for
interpolation. (In hiera-1, it is not recommended to attempt to lookup
anything but top scope variables - IIRC the documentation says so).
The only reasonable value of binding to other variables is if they are
also bound values. It is not possible in hiera-1 to bind a value to
another bound value. Bindings in modules (in hiera-2 data) however
allows this since it is possible to call functions in the hiera data. (A
more direct approach is also available in the ruby based bindings -
binding to the lookup of another value, or to the first found in a
series of lookups).
The reasons for this is that it is not possible to know when authoring
the data where this data will be looked up and allowing interpolation
from the calling scope is quite bad.
So yeah - top scope only.
Finally, if this is not the place to post these kinds of questions
please tell me where to do so.
This is a good place - the feature is experimental, and thus closer to
development than regular user questions. Plus, there are far fewer
messages in puppet-dev so less risk it goes unnoticed.
And please do fire away with questions. We can also set up a hangout if
you like to talk things through live (others invited too).
Cheers, and thanks for the feedback and time to experiment.
Hope the samples/info above gets you further.
Regards
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
