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