On Tue, Sep 26, 2017 at 4:01 PM Sean <[email protected]> wrote:
> Greetings,
>
> I have read searched and read several threads in the list regarding using
> hiera, automatic lookup, and class params. Some of them, I'm thinking
> relate to Puppet3 and prior, and I admit I'm struggling a bit with weeding
> through the information that's appropriate to my scenario of versions.
> Please bear with me. I am attempting to build a module that will use Hiera
> data layers and get away from the params.pp pattern. The hope is that
> customers can use their environment hiera data if they choose, global data
> from an ENC, accept the default module layer data or use resource
> definition and supply data directly. Unfortunately the module is complex
> and has many sublcasses, the init.pp looks something like:
>
> class complex (
> Array $class_incl_list,
> Array $class_excl_list,
> Boolean $enable_feature1,
> ...more params that subclasses might use...
> ) {
>
> validate_array($class_incl_list)
> validate_array($class_excl_list)
>
Since you have already specified `Array` on the params, you can skip the
`validate_array()` call here.
>
> $local_incl_list = array_subtract($class_incl_list, $class_excl_list)
>
> include $local_incl_list
>
> }
>
> The class arrays are strings of fully qualified subclass names, e.g. [
> 'complex::redhat::subclass1', 'complex::redhat::subclass2', ] etc.
>
> Is there a benefit to actually using class params or declaring all
> references to class variables directly as fully qualified in the subclasses?
>
`include` is necessary to make the class - and its resources - available in
the catalog. It has no influence over variable namespacing/scope.
If that doesn't answer your question, likely I haven't really understood
what you were asking.
> Here's a simplified example subclass, and yes the example is silly, if we
> enable/disable a feature in puppet code, why not just exclude the subclass
> altogether.
>
If you need to have stuff done to *remove* a feature, this pattern is
absolutely fine!
> Typically, that is what happens, but I was failing to find any other
> simplistic examples to provide.
>
> class complex::redhat::subclass1 (
> Boolean $enable_feature1,
> ) {
>
> if $enable_feature1 {
> notify("${::osfamily} Feature 1 is enabled")
> } else {
> notify("${::osfamily} Feature 1 is disabled")
> }
>
> }
>
>
> Would I be better off removing the class param and using
> $::complex::enable_feature1 in the conditional?
>
Yes.
> The subclasses aren't really meant to be called by the end-user
> directly, so I would never expect to see someone doing a resource
> declaration of a subclass, but I would expect to see a user doing a
> resource declaration of the main class and supplying the enable_feature1
> boolean with it.
>
> Thanks for your thoughts and input.
>
Cheers, David
> --
> 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/f374a512-e5a1-4933-bc0e-405bbc8b44f9%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/f374a512-e5a1-4933-bc0e-405bbc8b44f9%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CALF7fHadtWaMaxmHc%2BSf8bfk10ShQ8aNAv3d3oC_Nc-D8GxBxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
