John, what made me say that is the thread. He was trying to apply a class
to a node in his Hiera data that doesn't have an init.pp. It seems like he
is new to class namespacing and didn't know how to apply a class that
wasn't in init.pp. That's the discussion we were having.
I may have misunderstood his last message, rereading it now. I thought he
thought he could declare the class by including those lines. It was late
and it looks like I missed what he was trying to do. I'm not sure though
because it still wasn't working for him. Your YAML looks good to me though
and I think that should work.
But I was absolutely not saying that Hiera data is just a list of classes
that you include on your node. That would be a pretty silly thing to say,
right? I was speaking in the context of the original message, he and I had
an ongoing discussion.
Honestly I'm not sure why you would assume that's what I was trying to say.
I think you and I write/communicate differently. When I post a message here
I'm not trying to make sweeping declarations about how things work, I'm
trying to help someone with the problem they asked about.
Rich
On Tue, Sep 1, 2015 at 6:40 AM jcbollinger <john.bollin...@stjude.org>
wrote:
>
>
> 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
> <https://groups.google.com/d/msgid/puppet-users/6a183a91-056e-4ae1-8103-fc05f65ad04c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit 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/CAPGcbtCDb8EJLAc%3DjiX%3DBkbYiS9%2Bv5tKyB51OLJkFZAqfywPBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
