On Nov 8, 4:41 am, "Al @ Lab42" <lab42...@gmail.com> wrote:
> On Friday, September 30, 2011 4:50:33 PM UTC+1, jcbollinger wrote:
> > I do think there's a bug, but I'm not confident it's the one you think
> > it is. I find no documentation of any difference in variable
> > interpolation in class parameter defaults than in any other context,
> > so I expect the interpolation to be performed according to the same
> > rules as elsewhere. Specifically, I expect interpolation to draw on
> > only variables available in the scope in which the host string
> > appears. A class's parameters cannot be in scope in that class's own
> > parameter list definition, because their values are not known at that
> > point. Therefore, you should not be able to interpolate one
> > parameter's actual value into the default value of a another
> > parameter. That is, NONE of the interpolations in your example should
> > work.
>
> Hi John,
> This thing scaries me a bit.
> I'm rewriting my modules in order to merge the usage of a params.pp class
> where defaults are set and parametrized classes.
> The output is something like :
>
> class openssh (
>
> [...]
> $package = $openssh::params::package,
>
> $service = $openssh::params::service,
> $service_status = $openssh::params::service_status,
> $process = $openssh::params::process,
> $process_args = $openssh::params::process_args,
> $config_dir = $openssh::params::config_dir,
> $config_file = $openssh::params::config_file,
> $config_file_mode = $openssh::params::config_file_mode,
> $config_file_owner = $openssh::params::config_file_owner,
> $config_file_group = $openssh::params::config_file_group,
> $config_file_init = $openssh::params::config_file_init,
> $pid_file = $openssh::params::pid_file,
> $data_dir = $openssh::params::data_dir,
> $log_dir = $openssh::params::log_dir,
> $log_file = $openssh::params::log_file
> ) inherits openssh::params {
>
> There is no particular interpolation on variables, just their value's
> assignment as default.
> Is this a supported behaviour that I can trust to be mantained on future
> versions?
I do not work for PuppetLabs nor contribute code to Puppet. With that
said, however,
1) This precise approach is used in an example on the PuppetLabs
documentation site, and
2) it is not what this thread was previously discussing.
Specifically, this thread was not about generally using variables as
or in class parameters' default values; instead, it was about using
some of a class's *own* parameters as or in the default values of
others of that class's parameters. I haven't changed my mind on that
topic.
As to your approach, I think it should work now and in the future, in
the sense that it will reliably set the superclass variables' values
as the default values for the subclass's parameters. My personal
opinion, however, is that class parameterization is generally a bad
idea, that class inheritance should be used only for overriding
resource properties, and that going against both of those precepts at
the same time is ... something I can't see myself ever doing.
John
--
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.
