On 2014-05-11 15:45, Joshua Hoblitt wrote:
On 11/04/2014 09:09 PM, Joshua Hoblitt wrote:
On 11/04/2014 01:04 PM, Andy Parker wrote:
It would also provide at lot more confidence that a manifest is
4x safe
if it passes `puppet parser validate`. Without that you'd have
to worry
about conditional expressions silently changing their result
between 3x
and 4x.
The error would have to be at runtime, so puppet parser validate
would not uncover these kinds of issues (except perhaps in trivial
cases where it could be done). I have an experiment for creating a
type inference system, but it is no where near complete enough to be
a static type analysis system for puppet 4, and even then it would
have to give up in far too many cases without yet more changes to the
language.
Your absolutely right but `puppet master --compile localhost
--manifest manifests/role/db.pp` would work. Similarly, rspec-puppet
tests would catch an exception from building the catalog even if there
isn't coverage of the expression result. Perhaps an option could be
added to the parser face to eval expressions?
Actually, I think I'm full of it. It appears that although the master
face accepts the --manifest, --modulepath, etc. flags in combination
with --compile they don't have any visible effect on the generated
catalog (my catalogs are so large it was hard to tell). In any event,
the magic behavior I was hallucinating was parsing the supplied manifest
and then evaluating it with cached facts (is --compile pulling facts out
of inventory?).
Upon further consideration, there are significant problems with trying
to implement a generic parse+evaluate checker that can be used in the
same manner as `puppet parser validate` on arbitrary DSL code. Defined
but not declared classes / defined types may fail due to mandatory
params, the use of evaluation order dependent functions (defined(),
getparam(), etc.) and the `$caller_module_name != $module_name` idiom
are all gotchas.
Still, I wonder if it's possible to use the parser to fish out the names
of classes without mandatory parameters from of a series of manifests
and automagically perform the equivalent of rspec-puppet|`it { should
compile }' or 'it { should compile.with_all_deps }`|? I suppose facter
would either need to be invoked locally or an external corpus of facts
would need to be supplied. Hmm.
At cloudsmith we patched rspec-puppet to be able to feed in a set of
captured facts from a node. I think that is a feature that is missing in
rspec-puppet.
You can indeed to introspection of what is being parsed with the future
parser (the older parser is not completely side effect free and should
not be used for things like this). While not difficult, it does require
some coding to parse content and then find / filter the returned ast model.
You can also dump the parsed result as s-expressions (i.e. lisp like
tree) that shows the content of the ast model using puppet parser dump
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/m3e0ev%24tl7%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
