Feature #7195
closed
Deeper inspection of puppet classes to parse values from params.pp pattern
Added by Dominic Cleal almost 10 years ago.
Updated about 5 years ago.
Description
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1132421
Description of problem:
The 'params.pp' pattern in puppet to store default values is common. In the init.pp, you'll inherit from params and set default values as such:
$hostname = $module::params::$hostname
It would be good if Satellite supported this and was able to inspect deeper into the puppet modules to retrieve the default values.
Version-Release number of selected component (if applicable):
6.0.3 Beta
How reproducible:
Always
Steps to Reproduce:
1. Add a new puppet class that uses the params.pp pattern. For example, puppetlabs/ntp
2. View Smart Class Parameters for $autoupdate
Actual results:
Default value will appear as '$ntp::params::autoupdate'
Expected results:
Default value appears as 'false' (and some UI indication it was evaluated from params.pp)
Related issues
1 (1 open — 0 closed)
- Subject changed from [RFE] Deeper inspection of puppet classes to parse values from params.pp pattern to Deeper inspection of puppet classes to parse values from params.pp pattern
- Category set to Puppet
This would only be possible at a very basic level, if the value was outside of any conditionals, didn't use a selector, facts etc.
- Related to Tracker #4470: Usability of parameters and overrides added
Yea, I realize it's a bit difficult. It might not be really possible to do this well, but I can understand why a user might want to see the data, though.
Fixing puppet rdoc viewing, and perhaps being able to browse the Puppet code would be enough.
As it stands, the workflow is a bit difficult when using Katello, as a user has to traverse into the dark depths of the file system to a directory full of obscurely named `Katello_ACME_Corporation_Test_6` directories to find the relevant module's code to understand what the defaults are.
We wanted to migrate smart proxy to use kafo_parsers gem which should give us more information but I haven't find time to do it yet. Validations could also be useful (limited to first AST level though). In comparing to kafo it's missing real default values because you'd have to run puppet to get them but at least it can parse some of them.
I have actually taken a big stab at this with a unrelated project. This is definitely pretty complex. I have been able to resolve some variables but I haven't covered every case. I also have not resolved inherited variables yet. But it should be easy enough with what I have so far. The tricky bit here is that the AST parser is gone in 3.7.4 so we would have to depend on an all new parser with puppet 3.7.4+. This means that we may have to bring our own puppet version to ensure we have the intended parser to parse the manifest.
Below is my repo that contains some of the logic to break apart the manifest to find variables. I am not promising anything here but I know a lot about the subject from this pet project.
https://github.com/logicminds/puppet-retrospec/tree/development
- Status changed from New to Rejected
This is no longer possible since we're dropping Puppet 3 and the Puppet REST API doesn't expose this.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by