Classes and hiera

[Alfredo De Luca]

Hi all.
It might be a simple question for you.

In hiera I have the followings

protest::logdir: '/tmp/'
protest::logfile: fred
protest::text: 'ok ok was here'

and the class is

class protest (
$logdir = $protest::params::logdir,
$logfile = $protest::params::logfile,
$text = $protest::params::text
) inherits protest::params {

$myfile = "$logdir$logfile"
file { $myfile:
ensure => file,
content => inline_template("<%= text %>\n"),
}
}

and all works fine but I am struggling to use the class from hiera like below


protest:
file1:
logdir: '/tmp/'
logfile: fred1
text: 'Alfredo1 was here'
protest:
file2:
logdir: '/tmp/'
logfile: fred2
text: 'Alfredo2 was here'


What do I need to modify in the class in order to use it like that?



--
Alfredo

[Hristo Mohamed]

protest:
  file1:
    logdir: '/tmp/'
    logfile: fred1
    text: 'Alfredo1 was here'
protest:
  file2:
    logdir: '/tmp/'
    logfile: fred2
    text: 'Alfredo2 was here'

This I believe is incorrect.

protest:
  file1:
    logdir: '/tmp/'
    logfile: fred1
    text: 'Alfredo1 was here'

  file2:
    logdir: '/tmp/'
    logfile: fred2
    text: 'Alfredo2 was here'

This will return you a hash, and then you gotta figure out what you you want to do with the hash.

--
Alfredo

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAAWpFTGAdFxy4%3DSdDKJ14hBhiZHuAzehUv%2B2v20sLJopsaJW_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

It depends on what you mean by "like that".  In the first place, you cannot have duplicate keys in hiera, and cannot have the same class appearing more than once in any node's catalog.  In the second place, the Hiera keys used with automated binding of class parameter values are determined by the class and parameter names; you are not at liberty to choose arbitrary names.

If your objective is to manage multiple files via class 'protest', then you could rewrite it something like this (requires the future parser and the "stdlib" module; untested):

class protest (
  $files           = [],
  $default_logdir = $protest::params::logdir,
  $default_logfile = $protest::params::logfile,
  $default_text   = $protest::params::text
) inherits protest::params {
  # need to generate full file names from (dir, name) pairs
  # it's helpful to also fill in default values here
  $full_filedata = $files.map() |$filedata| {
    {
      path => join([
        (haskey($filedata, 'logdir') ? { true => $filedata['logdir'], default => $default_logdir}),
        (haskey($filedata, 'logfile') ? { true => $filedata['logfile'], default => $default_logfile})
      ], ''),
      text => (haskey($filedata, 'text') ? { true => $filedata['text'], default => $default_text})
    }
  }

  $full_filedata.each() |$file| {
    file { $file['path']:
      ensure => 'file',
      # no need for an inline template just to interpolate a variable's value:
      content => "${file['text']}\n",
    }
  }
}

The data to go with this would need to be structured like so:

protest::files:
  - logdir: '/tmp/'
    logfile: fred1
    text: 'Alfredo1 was here'
  - logdir: '/tmp/'
    logfile: fred2
    text: 'Alfredo2 was here'
protest::default_logdir: '/tmp/'
protest::default_file: 'log'
protest::default_text: ''

This example goes to considerable effort to preserve the multiple levels of default values afforded by your original code, but it may be that that is unneeded, in which case the class could be simplified, and maybe the data, too.

On the other hand, this class does no data validation whatever.  A robust implementation would check the input data and fail with a meaningful diagnostic in the even that the data were not structured correctly or had inappropriate values.


John

[Alfredo De Luca]

Hi John et al.
Thanks for this example. It's much clear for me now.

Thanks

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/puppet-users/38404ec6-1921-4a9c-b43f-f4d96ece56f1%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Alfredo