When I leave just the class declaration it works:
>
>
>> class {'postgresql::server::contrib':
>> }
>>
>
>
> Well if that serves your needs (and it should) then it is better form to
> use an include-like declaration instead:
>
> include 'postgresql::server::contrib'
>
> But that's mostly a style consideration. It will affect behavior only if
> now or in the future there is a(nother) resource-like declaration of that
> class somewhere in your manifest set.
>
>
Excellent.
>
> Is there a way to have the class declaration in hiera? I tried using this
>> at the top of my yaml file but it didn't work:
>>
>> ---
>> classes:
>> - postgresql::server::contrib
>>
>
>
> Hiera just provides data and metadata. It does not have any inherent
> behavior associated.
>
> But that absolutely can have the form of an array of class names, which
> can even be spread across multiple hierarchy levels, and you can use that
> array to declare the named classes. The old way was to use the
> hiera_include() function in one of your manifests, but in recent Puppet
> (4.x and later) you should be using the lookup() function and regular
> include() function:
>
> include(lookup('classes', Array[String], 'unique', []))
>
>
>
>>
>>
>>>
>>>
>>>> So class parameters are automatically looked up in hiera, but define
>>>> parameters (or whatever name it is for objects) is not?
>>>>
>>>
>>>
>>> That is correct. There are good reasons for it, but a discussion of
>>> those would be tangential. If you're interested, you can find at least one
>>> such discussion in the archives of this group.
>>>
>>>
>> Ok thanks,
>>
>> Are the modules supposed to manage that or the user?
>>
>
>
> Whoever declares a resource instance or a class is responsible for binding
> the appropriate values to its parameters. In particular, modules are
> responsible for binding appropriate data to the resources and classes that
> they declare internally, but you are responsible for binding values to the
> resources and classes that you declare, regardless of where the class or
> resource type is *defined*, and, for resources, regardless of whether
> they are of plug-in or defined type. If one interprets "the user" as
> "whoever is responsible for the declaration" on an entity-by-entity basis,
> then that simplifies to the user being responsible for managing parameters.
>
I see. During my testing I found out that if I use create_resources and
put nothing about it, it throws an error.
>
> Of course, where a resource type or class defines default values for its
> parameters and those values meet your requirements, it's fine to rely on
> those. You don't necessarily need to explicitly provide a value for every
> parameter. And do note the important distinction between *declaring* a
> class or resource, and *defining* a class or resource type.
>
This is something that I have always had trouble understanding and lacked
time to read more on it. And even if I read on it...
>
>
> John
>
>
Thanks John. You and Arnau are simply amazing. I say something similar
almost every time I post on this group, but this group provide better
support than *any* of our software/hardware vendors. Faster support, and of
better quality. Kudos to all the people who participate here.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/17e6e035-8fa4-48a0-8b78-e4e6752f6b37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
