[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...
Regards,
-Matt
--
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+unsubscribe@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.
On 03/05/2013 09:14 AM, Matthew Barker wrote:> 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.Hi, is the use of the $somevariable that yields this warning actually in the class { } block? -- 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+unsubscribe@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.
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+unsubscribe@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.
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+unsubscribe@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.
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+unsubscribe@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.
The real question to me is: Which line needs removing to make the
warning go away?
I''d put my money on the "Unqualified ${test}" one, seeing as
the string
concatenation fails too. The Scope(...) in the syslog is confusing.
So you may want to report a bug, but if you do, please limit the
manifest to the minimum to trigger the warning.
Cheers,
Felix
On 03/07/2013 12:02 PM, Matthew Barker wrote:> This module will reproduce the syslog messages I was referring to.
> http://pastebin.com/tBuyBEBW
--
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+unsubscribe@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.
On Thursday, March 7, 2013 5:02:44 AM UTC-6, Matthew Barker wrote:> > > This module will reproduce the syslog messages I was referring to. > http://pastebin.com/tBuyBEBW > >Sorry, pastebin is blocked from me. 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+unsubscribe@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.