Project

General

Profile

Actions

Feature #7195

closed

Deeper inspection of puppet classes to parse values from params.pp pattern

Added by Dominic Cleal over 9 years ago. Updated almost 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Puppet
Target version:
-
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

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 open0 closed)

Related to Foreman - Tracker #4470: Usability of parameters and overridesNew

Actions
Actions #1

Updated by Dominic Cleal over 9 years ago

  • 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.

Actions #2

Updated by Stephen Benjamin over 9 years ago

  • Related to Tracker #4470: Usability of parameters and overrides added
Actions #3

Updated by Stephen Benjamin over 9 years ago

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.

Actions #4

Updated by Marek Hulán over 9 years ago

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.

Actions #5

Updated by Corey Osman about 9 years ago

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

Actions #6

Updated by Ewoud Kohl van Wijngaarden almost 5 years ago

  • 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.

Actions

Also available in: Atom PDF