On Fri, May 13, 2011 at 11:01 AM, Aaron Grewell <aaron.grew...@gmail.com> wrote:
> I converted a set of classes from include/scope to use the parameterized
> syntax yesterday, and I ran into an odd behavior that might be considered a
> bug. I defined a class somewhat like this but more complex:
>
> class vmware ( $pkg_list) {
> package { $pkg_list:
> ensure => "installed",
> provider => "yum",
> require => Yumrepo["vmtools","vmtools-updates"],
> } # package
> } # class vmware
>
> And then called it like so:
>
> class {'vmware':
> pkg_list => ['vmware-tools'],
> yumPatchDate => $yumPatchDate,
> }
>
> I ran this on the client and it did... nothing. I almost generated an
> e-mail to this list about it but after pasting the example into the e-mail I
> realized my obvious error. I removed the extra parameter from the call and
> then it worked fine. My question is should this kind of mistake generate an
> error? Given that no class 'vmware' is defined that accepts two parameters
> I would expect so. Instead it just silently fails. I'm using Puppet 2.6.6
> from EPEL so it's also possible that this has been fixed upstream somewhere
> and I'm just not aware of it. It's also possible that there's some
> syntactical reason why there's no error, some way this could be valid if I
> was using a special feature or code pattern. Does this issue ring a bell
> for anybody?
>
Nope, it should generate invalid parameter error. I was not able to
reproduce in 2.6.8 or 2.6.6, both generated the appropriate error:
Invalid parameter yumPatchDate at ...
You probably have another implementation of this define supporting
this parameter that's getting autoloaded,
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
