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 puppet-users+unsubscr...@googlegroups.com.
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.
