On Tue, Feb 10, 2015 at 06:52:05AM -0800, jcbollinger wrote:
> On Monday, February 9, 2015 at 10:37:39 AM UTC-6, Christopher Wood wrote:
>
>
> I'm dealing with a config file template where most options are always
> turned off. I'm also trying to get our puppet agent runs to fail with
> catalog compilation errors if they can't look up a hiera value, so there
> are no default values in the class parameters. (Exploring if catalog
> compilation failure is safer than the possibility of populating a config
> with default values.)
>
> If I could list a bunch of obvious 'undef' style items in hiera that
> might be handier than listing 'false', given that the meaning of
> 'configitem=false' is different in this config than an absent
> configitem.
>
> You're having trouble because you're being inconsistent. If it is
> meaningful and supported for a class parameter to be absent, then why are
I don't think I phrased that too well. Inside the config file any given item
may be present in its default or non-default values but it's customary here
that defaults are left out of this config file. Think never specifying "Listen
80" in httpd.conf and having Apache listen on port 80 anyway.
> you trying to force it to be present in the data? On the other hand, if
> you mean to force a value to be specified for the parameter, then why are
> you trying to affirmatively specify no value?
There are two behaviours when a class parameter hiera lookup fails to find
anything, the one with a default value and the one without a default value.
class this ( $param = undef ) {
# stuff
}
class that ( $param ) {
# stuff
}
With the former, the true/false handling would leave a config parameter out of
the config file. With the latter, the failure mode is catalog compilation
breakage, something which fails an agent run but whose consequences are more
immediately visible. These days I prefer making the results of affirmative
decisions immediately visible to presuming the continued viability of a past
default.
> Hiera aside, I don't much care for your design here. Either allow the
> parameter to be unspecified, including via Hiera, or designate an actual
> value the class parameter can take to specify that the corresponding
> config option is to be omitted from the target file ("absent" would
> probably be the conventional choice for that).
I thought so too, and then wondered if it's worth keeping a consistent
interface between modules. If one class parameter default is undef and another
is '80', that means the admin building a new role gets to figure out which
parameters require their attention and which can be left as defaults. "Pay
attention to all the parameters or catalog compilation fails" seems a safer
message, especially with so many separate hiera keys across our installation.
[puppet exp] $ grep -rh '^[a-z]' hieradata | awk '{print $1}' | sort -u | wc -l
390
[puppet exp] $ grep -rh '^[a-z]' hieradata | awk '{print $1}' | wc -l
2561
(Not all 390 separate keys apply to each server, of course.)
> John
>
> --
> 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 [1]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/8c7bf563-8155-483b-921e-9c2ee51f0c80%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users+unsubscr...@googlegroups.com
> 2.
> https://groups.google.com/d/msgid/puppet-users/8c7bf563-8155-483b-921e-9c2ee51f0c80%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout
--
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/20150210154552.GA3338%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
