Hi David, thanks for your reply.
I can see where I may have confused the intent of my questions with too
much information. If someone using the class were to declare something
like:
class { 'complex':
enable_feature1 => false,
class_incl_list => [ 'complex::redhat::subclass1', ],
}
Will subclass1 obtain the value of enable_feature1 from the above
declaration? Suppose the module default in data/common.yaml for
enable_feature1 is true.
On Tuesday, September 26, 2017 at 12:13:42 PM UTC-4, David Schmitt wrote:
>
>
>
> On Tue, Sep 26, 2017 at 4:01 PM Sean <[email protected] <javascript:>>
> 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] <javascript:>.
>> 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/94f61b8e-94b1-4023-bb84-7eb64de07fa5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
