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.
> On Monday, November 3, 2014 3:03:51 PM UTC-7, Felix.Frank wrote:
>
> 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
>
> On 10/14/2014 11:17 PM, Craig White wrote:
> > 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
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/545824E4.9090904%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.
