On Tuesday, February 10, 2015 at 9:48:50 AM UTC-6, Christopher Wood wrote:
>
> 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.
>
>
I understand. Really. And my question stands. In your example, if you're
ok with a value for the 'port' parameter not being specified to your class,
as embodied by having some kind of appropriate handling in the event that
Hiera should somehow affirmatively declare that parameter unspecified, then
'port' is an optional parameter. Optional parameters are implemented in
Puppet by assigning default [non-]values to them in the parameter list.
> > 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.
>
That's reasonable. The fact remains that Hiera does not inherently provide
any generic way to affirmatively declare that you're not specifying a
parameter value. Even if it did, it would be unlikely to have the
semantics you're after, because -- I repeat -- what you're asking is
inconsistent. If a parameter is required, then there is no practical
difference between its value being accidentally unspecified and its value
being affirmatively unspecified: either way, a required parameter is
unspecified.
Note well: *Puppet DSL's 'undef' keyword does not represent a value*. It
represents the *absence* of any value. If you write a resource-style class
declaration that associates keyword 'undef' with a class parameter, it is
equivalent to not specifying that parameter at all. If you assign the
keyword 'undef' as a class parameter default, it marks the parameter
optional with no default value -- if no actual value is given for that
parameter then it will not have a defined value. If you override a
resource parameter to be undef, it makes the resource be treated as if no
value were explicitly assigned (in particular, that parameter takes its
default value, if any).
>
> > 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.
>
>
Your admins are responsible for every parameter anyway. You can make
Puppet enforce that they give at least nominal attention to each, but I
don't think it gains you much ground. Were *I* an admin working under such
a system, I would be inclined to bootstrap a new role by copying data from
one or more existing ones, or maybe to create a set of default data for the
purpose. Either one renders your effort moot. It will be hard to prevent
admins working around your enforcement approach, and putting such a regime
in place sends a message that you do not trust them to do their jobs
correctly. (And even if you don't, I advise you to avoid sending such a
message.) If you ask me, the message should be "Ensure all the parameters
have correct values, else machines will be misconfigured". Focus your
people on the result rather than on the process, and *test* the result.
With that said, if you want to enforce that there be some kind of physical
manifestation of a value [non-]choice for every class parameter, enforced
by compilation failure when such a manifestation is not present, then you
can avoid all class parameter defaults, and implement some actual value
that consistently and generically represents non-specification of any real
value. Something unlikely to be desired as a real value for any class
parameter would be wise, such as maybe '__absent__' or '__default__'. You
can move any actual default values into the class bodies.
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2fab11a3-4167-48f2-8813-1e606ed38360%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
