Thanks Felix & John,
Here is a bit more info. I fiddled a bit more and wrote this little
scope module to make sure I wasn't seriously confused.
Tonight, the message seems to be consistently happening regardless of
how I name the parameters in this one.
Not sure how I managed to get them to disappear last night and can't
reproduce the behavior. I blame the IPA ;)
See the pastebin to see the message/sample code.
http://pastebin.com/wYAPsHWn
I misspoke with subclass (not inheriting); just another class under an
implementation path I guess.
In the original module, the variable is referenced in the class body
itself by a file resource.
It's probably something silly; any idea what causes that syslog message?
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.
