Thanks Felix and John,
Here is a bit more info. I wrote this little test module to make sure I
wasn't seriously confused.
This module will reproduce the syslog messages I was referring to.
http://pastebin.com/tBuyBEBW
The message seems to occur regardless of what I do with the parameters in
this one; not sure how I managed to get them to go away last night and
can't reproduce the disappearance. I blame the IPA ;)
I misspoke with subclass (not inheriting); just another class in an
implementation path I guess.
The parameters are being used within the class block in the original module
I spoke of.
I'm sure it's something silly. Any idea what might cause these syslog
messages?
Thanks,
-Matt
On Wednesday, March 6, 2013 6:10:31 AM UTC-8, jcbollinger wrote:
>
>
>
> On Tuesday, March 5, 2013 2:14:40 AM UTC-6, Matthew Barker wrote:
>>
>> [Puppet v3.1.0 both on the master and client (debian squeeze)]
>>
>> So, I'm porting a pretty monolithic module over from our 2.6.x puppet
>> environment to a new puppet 3.1.0 environment and ran into some
>> notifications in syslog from the puppetmaster.
>>
>> I have a module/class that instantiates numerous parameterized subclasses.
>>
>> class my_class {
>> class {"my_class::some_implementation::parameterized_subclass":
>> somevariable => true,
>> }
>> ...
>> }
>>
>> and...
>>
>> class my_class::some_implementation::parameterized_subclass
>> ($somevariable = false) {
>> #do stuff
>> }
>>
>> So, all works fine, but I get scope & qualified variable notifications on
>> the puppetmaster. If I change my_class::parameterized_subclass to the
>> following, it goes away.
>> class my_class::some_implementation::parameterized_subclass
>> ($my_class::parameterized_subclass::some_implementation::parameterized_subclass::somevariable
>>
>> = false) { }
>>
>> That seems a bit bizarre to me (and annoying). Is there a scope behavior
>> I'm missing that would prevent this type of class layout? Any ideas?
>> Think of a layout like:
>> base::security::ossec
>> base::monitoring::rsyslog
>> base::monitoring::munin
>>
>> etc...
>>
>>
> It sounds bizarre to me, too, but you haven't given us very much to work
> with -- neither actual error messages nor code that causes them to be
> emitted (I am confident that the example code you posted will not do so).
> At this point, my only guess is that:
>
> 1. You really do mean "subclass" in the class inheritance sense, even
> though you do not show that in your example code, and
> 2. the base class has a variable (possibly a parameter) with the same
> name as the affected subclass parameter.
>
> If that's what's going on then either break the class inheritance
> relationship (it probably is not necessary, and likely does not do what you
> think it does), or have the subclass use its' parent class's variable
> directly, referring to it by its qualified name.
>
> If you want a more confident analysis or better considered advice, then
> show us code (even model code) that actually produces the diagnostics you
> describe.
>
>
> John
>
>
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
