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.
