is it possible to inherit parameters in hieradata

[Priyo Phan]

I am configuring logrotate and was wondering if i can inherit parameters , my common.yaml is given below :- 

classes:

  - logrotate

logrotate::hieramerge: true

logrotate::rules:

  syslog:

    path:

      - '/var/log/messages'

    compress: true

    compresscmd: '/usr/bin/gzip'

    uncompresscmd: '/usr/bin/gunzip'

  application:

    path:

      - '/var/log/application'

    compress: true

    compresscmd: '/usr/bin/gzip'

    uncompresscmd: '/usr/bin/gunzip'

Every time I have to put compress* and uncompress , is there a way whre i can inherit those from a parent .

[Robert]

Yes.

https://puppet.com/docs/puppet/5.0/hiera_merging.html#hash

So you could use a "logrotate::rules::defaults" hash and only specify the differences, then use hash (or maybe deep) merge strategy.

Best,

Rp

--
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/7fa51816-e9c3-4a2b-9ad9-54be3f8c3efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Saturday, June 9, 2018 at 10:23:34 AM UTC-5, Robert wrote:

Yes.

https://puppet.com/docs/puppet/5.0/hiera_merging.html#hash

So you could use a "logrotate::rules::defaults" hash and only specify the differences, then use hash (or maybe deep) merge strategy.

Well no, not like that.  Hiera merging applies to values associated with the same key, but residing in different hierarchy levels.  That's not the at all the case the OP presented.

John

[jcbollinger]

Supposing that your common.yaml is the lowest level of your hierarchy, as is conventional, there is no lower level from which to obtain parameters.  Moreover, neither the data you are expressing nor the resources you are declaring based on them have a "parent" in any applicable sense.

However, taking a higher-level view, I suspect that what you're after is not so much mechanism but result: you want to declare a compresscmd and an uncompresscmd value once each, and have them apply to all logrotate::rules.  There are several viable alternatives if you are in control of the class that declares those resources, but I'm guessing that in your case, the resources are declared by a class from a third-party module (maybe puppet-logrotate), which you therefore do not want to modify.

Supposing that the data are being used as resource parameters, however, at least two viable approaches still remain: resource defaults and resource overrides.  If they work for you (and there are reasons why they might not) then top-scope resource defaults would be my choice.  Here's how that might look:

environments/myenvironment/data/common.yaml:

---
classes:
  - logrotate
logrotate_rule_defaults:
  compresscmd: '/usr/bin/gzip'
  uncompresscmd: '/usr/bin/gunzip'

 
logrotate::hieramerge: true
logrotate::rules:
  syslog:
    path:
      - '/var/log/messages'
    compress: true

  application:
    path:
      - '/var/log/application'
    compress: true

environments/myenvironment/manifests/logrotate_defaults.pp:

Logrotate::Rule {
  * => lookup('logrotate_rule_defaults', 'Hash', 'priority', {})
}

That sets default values for the properties of resources of type logrotate::rule, and because it appears at top scope, it will apply to all logrotate::rule instances declared anywhere in your manifest set.

You should check, however, whether the module you're using already has a provision for this.  If you do happen to be using puppet-logrotate in particular, for instance, then you should look into its `logrotate::conf` resource type, which is supposed to serve this purpose.

John

[Priyo Phan]

Thanks for all the tips  , works fine with logrotate::conf declaration .