(PUP-10476) PAL additions to support more use cases from bolt #8142
Conversation
Previously, when using functions like .with_catalog_compiler and setting variables the variables sent were assumed to be simple types. If the vars sent are serialized PCore, we should attempt to deserialize before setting them.
|
Raised this draft to show how we might use it in bolt. puppetlabs/bolt#1798 |
| # In case the varaibles passed to the compiler are PCore types defined in modules, they | ||
| # need to be deserialized and added from within the this scope, so that loaders are | ||
| # available during deserizlization. | ||
| add_variables(compiler.topscope, Puppet::Pops::Serialization::FromDataConverter.convert(pal_variables)) |
There was a problem hiding this comment.
Why cant we add give
puppet/lib/puppet/pal/catalog_compiler.rb
Line 10 in f29b968
There was a problem hiding this comment.
We can, but it seems incorrect to me that PAL would provide parameters for setting variables and not have them work for anything other than core puppet datatypes.
If PAL supports providing variables as a parameter to .with_catalog_compiler it should support those variables if they are datatypes defined in modules too.
This commit adds evaluate_node_ast as a public function available to the catalog compiler inside PAL's .with_catalog_compiler. When using .with_catalog_compiler, the calling process can now call compiler.evaluate_ast_node to compile any node definitions inside the manifest
|
I'm 💯 on updating PAL if it's not working for Bolt. Though I'll leave it to @puppetlabs/bolt to review if this is correct for them. |
|
CLA signed by all contributors. |
|
👍 This is great. |
6 participants
This commit makes two changes to PAL to support more features within puppet during a catalog compile:
.with_catalog_compilerthey are now deserialized if they are serialized pcore types.with_catalog_compilerso that a process calling PAL functions can evaluate ast with node definitions.