On Tuesday, September 1, 2015 at 1:59:10 AM UTC-5, Rich Burroughs wrote:
>
> Yeah that is not going to work.
>
> Your Hiera file is a list of classes you're including on the host,
What makes you say that? The Hiera fragment presented does not appear to
satisfy that description, and the description certainly is not a general
characterization of Hiera data.
> I'm assuming your code is using the hiera_include function. Basically
> Puppet is turning the classes listed in that file into an array and then
> trying to apply them all.
Certainly not. The hiera data presented are three separate keys / value
pairs. They appear to present parameter values for class postgres::server,
and as such they look fine. No standard Puppet function will combine these
into an array automatically.
> What you've done is try to include the same class three times. That won't
> work.
>
If that were what he had tried to do then it probably *would* work, because
Puppet has no inherent problem with the same class being declared multiple
times. It only becomes an issue when the resource-like class declaration
syntax employed, which is one of the major reasons to avoid that
class-declaration syntax.
>
> You would just do:
>
> postgresql::server
>
> Just that one line.
>
No, definitely not. That one line by itself is neither valid YAML nor
valid Puppet DSL, and that line is not a correct addition to the value of
the 'classes' key that was earlier presented. Replacing the current Hiera
data with that will make the problem worse, not better.
More generally, though, it very likely is the case that the problem Alfredo
last described is indeed that the 'postgresql::server' class is nowhere
declared. Including class parameter mappings among your hiera data is not
sufficient to cause the target class to be declared, largely because
recognizing the data as defining parameter mappings in the first place
depends on there being a class declaration.
Supposing that somewhere in one of the manifests that are being evaluated
for the target node there is a call to hiera_include('classes'), as the
originally-presented data suggest, it seems an appropriate way to include
'postgres::server' class among those applied to the node would be to make
the 'classes' entry in the Hiera data look like this:
classes:
- sudo
- selinux
- postgresql::server
(Note the indentation and leading hyphen.) Supposing that class parameter
values are to be provided via automatic data binding, Alfredo's alternative
Hiera data should be *added* to the file. It does not substitute for an
entry in the 'classes' array:
postgresql::server::db: test
postgresql::server::password: test
postgresql::server::user: test
Note, too, that the data binding and class declaration are almost entirely
orthogonal. Without any class declaration, the parameter binding keys are
(probably) unused, but not erroneous. Moreover, a class declaration
directly in DSL or via an ENC, instead of via hiera_include(), will draw on
those same parameter bindings for any parameters whose values are not given
in the declaration. Thus, for example, instead of including
postgresql::server in the 'classes' array, one could achieve the same
result, modulo evaluation-order effects, by declaring
include 'postgresql::server'
in one of the manifests that is evaluated for the node, parameter bindings
and all. The include() is a non-exclusive alternative to declaring the
class via hiera_include().
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/6a183a91-056e-4ae1-8103-fc05f65ad04c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
