Automatic parameter lookup including metaparameters

[Michael Watters]

Hello,

Is it possible to define metaparameters for a resource in Hiera?  For example, I have a class that is currently declared within another class as follows.

if !defined(Class['autofs']) {
        class { 'autofs':
            require => [
                Class['authconfig'],
                Class['nfs::client'],
            ],
        }
}

I would like to get rid of this mess and use a standard include statement with parameters defined in my common.yaml as follows.

include 'autofs'

---
autofs::require:
    - "Class['authconfig']"
    - "Class['nfs::client']"

Will this work or do I have to stick with resource-like declarations to define dependencies?

[Ben Ford]

Hi Michael. Can you share the code you tried and the errors you ran into?

--
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/ea13260d-673f-4322-a787-271c7f4b1259%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Watters]

The error I was getting was due to duplicate declarations of the autofs class as follows.

```

29) dart::abstract::aos_master_node on fedora-26-x86_64 should contain Logrotate::Rule[httpd] with path => "/var/log/httpd/*log", missingok => true, ifempty => false, sharedscripts => true, delaycompress => false and postrotate => "/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true"

      Failure/Error: include '::dart::subsys::autofs::common'

      

      Puppet::PreformattedError:

        Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Class[Autofs] is already declared; cannot redeclare (file: projects/puppet/modules/dart/spec/fixtures/modules/dart/manifests/subsys/autofs/common.pp, line: 35) (file: projects/puppet/modules/dart/spec/fixtures/modules/dart/manifests/subsys/autofs/common.pp, line: 35, column: 5) on node mdct-aos-master-f26.example.com

```

This occurs due to the dart::subsys::autofs::common class already being included by our base node class.  I've ran into this issue previously using resource-like declarations as well.

Adding the if !defined wrapper solves the issue but it still feels like a kludge instead of a proper solution.

[jcbollinger]

If you are going to definitely declare class autofs, as you show doing via an include statement, then your best bet is probably to use chain operators instead of metaparameters to express the wanted relationships:

include 'autofs'

Class['authconfig'] -> Class['autofs']
Class['nfs::client'] -> Class['autofs']

That combination means exactly the same thing as your resource-like declaration, and it makes no use of defined (which is good, because defined is evil).

Consider also, however, whether you actually need those relationships at all.  Is there in fact any reason for concern that applying class autofs before applying one or both of the other two might result in a Puppet failure or a target system misconfiguration?  Those are the kinds of problems that Puppet relationships solve.  It is neither necessary nor desirable to use relationships to express functional dependencies among the resources under management when they do not also impact the process of configuration management.

John

[jcbollinger]

On Tuesday, August 14, 2018 at 7:52:45 AM UTC-5, jcbollinger wrote:

include 'autofs'

Class['authconfig'] -> Class['autofs']
Class['nfs::client'] -> Class['autofs']

That combination means exactly the same thing as your resource-like declaration, and it makes no use of defined (which is good, because defined is evil).

To be clear, it means the same thing, but will not be the source of any duplicate declaration error.

John

 

[Michael Watters]

> Is there in fact any reason for concern that applying class autofs before applying one or both of the other two might result in a Puppet failure or a target system misconfiguration? 

In this case, yes.  In order for autofs to work properly NFS must be configured first and in order for NFS to work things like sssd, nsswitch.conf, PAM, etc. must be configured properly.  That is handled by our authconfig module.

I'll look into updating our manifest to use the chain parameters you mentioned.  Thanks for the help.

[jcbollinger]

On Thursday, August 16, 2018 at 11:27:26 AM UTC-5, Michael Watters wrote:

> Is there in fact any reason for concern that applying class autofs before applying one or both of the other two might result in a Puppet failure or a target system misconfiguration? 

In this case, yes.  In order for autofs to work properly NFS must be configured first and in order for NFS to work things like sssd, nsswitch.conf, PAM, etc. must be configured properly.  That is handled by our authconfig module.

You seem to have missed my point there.  I know and acknowledge that for Autofs to work properly for NFS filesystems, NFS has to be configured, etc..  But that does not imply that for Autofs to be installed and configured properly, NFS must already be installed and configured.  Puppet relationships address the latter kind of dependency, not the former.  In other words, they are not (directly) about how the target system works, but rather about how Puppet works.

John