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 puppet-users+unsubscr...@googlegroups.com.
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.
