parameterized values displaying tooltip on ENC

[Craig White]

I am trying to figure out if parameterized variables can be displayed when hovering over the appropriate section in an ENC. At the moment, I am playing with PE 3.3 with it's console/dashboard and my previous experience was with puppet 2.6.x and Foreman.

Simplified example, module resolv

# resolv/manifests/init.pp

class resolv (

  $ns1 = $resolv::params::ns1,

  ) inherits resolv::params {

  include resolv::config

}

# resolv/manifests/params.pp

class resolv::params {

  $ns1 = '192.168.0.1'

}

So when I am editing a node and adding an override in the puppet dashboard (ENC), I hover over the box $ns1 where I can override the value and it shows me what I will get if I don't override, which is 'default: $ns1::params::ns1' which is absolutely meaningless at that point and I was hoping it would show the assignment from params.pp

Is this just something I can't fix or am I misunderstanding how to use parameterized variables?

Craig

[Felix Frank]

Hi,

sounds like a complex problem.

Here's a simple counter case that shows why I don't think that any ENC
out there does this.

class resolv::params {
if $ipaddress =~ /^192/ {
$ns1 = '192.168.0.1'
}
else {
$ns1 = '8.8.8.8'
}
}

The raison d'etre (as far as I know it - never used this pattern myself)
for params classes is their ability to centrally define defaults that
are derived from fact values. The ENC would have to interpret the
manifest for the params class in question, using the node's stored data
as the basis.

Doing this on the fly does not sound feasible to me - this is quite an
expensive operation. So the ENC would have to maintain some kind of
cache for all those values. This, in turn, sounds like a lot of work.
The it probably would be a cool feature to add to the ENC of your choice :-)

Cheers,
Felix

[Craig White]

I believe the ENC already has access to the node's stored value and would display that after assignment if assigned. 

I didn't consider 'cost' but it would seem that loading 'params.pp' values is not a large cost in terms of server but perhaps just in programming.

I am just gathering that the primary thinking is that if you don't know the values you want to use to override, then don't override. 

Myself, I am trying not to longhand some of the variables and am choosing to use ns1 rather than nameserver1 

[Felix Frank]

On 11/03/2014 11:21 PM, Craig White wrote:

I believe the ENC already has access to the node's stored value and would display that after assignment if assigned.

I'm not so sure. The classes that are included from a node should be available, but I don't think that each last parameter value is being saved somewhere. That's just my gut feeling, though.

I didn't consider 'cost' but it would seem that loading 'params.pp' values is not a large cost in terms of server but perhaps just in programming.

Yes, the implementation would be complex. But in terms of computation, this *would* be expensive. To make sure that all values can be resolved, the entire manifest for the node in question will need parsing. It might be as simple as looking up a line from the body of the params class in many cases, but that would be a very limited algorithm that cannot work for all cases.

I am just gathering that the primary thinking is that if you don't know the values you want to use to override, then don't override.

Sorry - I don't follow.

Myself, I am trying not to longhand some of the variables and am choosing to use ns1 rather than nameserver1

Still not following.