Please explain need for multiple .ppm files in a single module

[warron.french]

Where I work a great of the Puppet Modules employed are downloaded from the Puppet Forge; however, some are created by my teammates.

What I can't figure out is WHY are some modules written with multiple .pp files in the manifest directory.

Can someone please tutor me on this point, or point me to a document/link?

Thank you,

[Rich Burroughs]

Check out the Class Design section here:

https://docs.puppetlabs.com/guides/module_guides/bgtm.html


Rich

--
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/CAJdJdQmqYjragWJo9AkHpQsb-k1db8nDDM1VE18oWOGV%3DMGVgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

What I can't figure out is what you find surprising about Puppet modules comprising multiple manifests.  If you help me out there, then perhaps I can help you out in return.


John

[warron.french]

JCBollinger, in my training classes over the last 3 years, we always wrote modules with a single init.pp; that's why I am surprised.

Thanks JC,

--------------------------
Warron French

--
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/e8ab98c0-64ec-4c10-8bb2-7ca833e424a4%40googlegroups.com.

[Denmat]

Here's what puppet docs say.

https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.html#manifests

One single .pp for complex modules are a nightmare. Better to separate into smaller chunks.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJdJdQk%2BP2M8CWawowJaBdwbn06fzo19PbT%2BFg-B12qKDMfdeg%40mail.gmail.com.

[warron.french]

Denmant, so, if I wanted to write my own module for the Audit configurations on a Solaris 10 {x86|sparc} and CentOS {x86_64} and I knew I needed to break it down (in my mind) as the following:

1. Configure audit rules (Solaris [audit_control] CentOS [audit.rules]) through auditMonitor.pp
2. Configure audit reporting (Solaris [audit_warn] CentOS [auditd.conf]) through auditReport.pp

Something like that would be appropriate, and a reason for separating functionality out to separate .PP files?

Does that mean the init.pp would call the other .PP files as I wanted them to be enabled or not?

--------------------------
Warron French

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0C7EA191-B366-4C53-819E-E2A5624535FC%40gmail.com.

[jcbollinger]

On Thursday, February 18, 2016 at 2:52:07 PM UTC-6, Warron French wrote:

JCBollinger, in my training classes over the last 3 years, we always wrote modules with a single init.pp; that's why I am surprised.

Training classes typically use small problems for their examples, and they often try to minimize complexity in other ways as well.  Nevertheless, if your classes gave you the impression that there was something inherently right about putting all your module code into init.pp, and especially if they taught you that using multiple manifest files was poor form, then I suggest you take everything else they taught you with a grain of salt.  Why did you think the module layout provides a whole directory for manifests if you were expected to use only one file?

The prevailing convention is to put each class and each defined type in its own manifest file, named and laid out according the class / type names.  Puppet can accommodate some other layouts -- including putting everything in init.pp -- but I almost never see anyone use other layouts in practice.  Of course, you may have the alternative of writing your whole module as a single class, and if you do that then you cannot use more than one manifest file.  But it is usually better form to use multiple classes, for many of the same reasons that programs in procedural programming languages are normally implemented in terms of multiple functions.


John

[warron.french]

Thanks John, that clears it up very well.

--
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/fff8d2d0-6da7-4f0f-8bf3-5f0520ceeb24%40googlegroups.com.

[Denmat]

On 20 Feb 2016, at 00:28, warron.french <warron...@gmail.com> wrote:

Denmant, so, if I wanted to write my own module for the Audit configurations on a Solaris 10 {x86|sparc} and CentOS {x86_64} and I knew I needed to break it down (in my mind) as the following:

1. Configure audit rules (Solaris [audit_control] CentOS [audit.rules]) through auditMonitor.pp
2. Configure audit reporting (Solaris [audit_warn] CentOS [auditd.conf]) through auditReport.pp

Something like that would be appropriate, and a reason for separating functionality out to separate .PP files?

Yep, sounds about right. Not trying to confuse you but they might be better expressed as 'profiles' which is just a further abstraction of modules. Depends on how different the conf data becomes. 

In that case you might end up having a profile (just another module) that collects data for Solaris ('profiles::audit_solaris') and and another for CentOS ('profiles::audit_centos').

They might call in 'audit::audit_monitor' or 'audit::audit_report' and pass config data collected there. (It is much more common to snake_case your modules - but not mandatory).

In that case you can have a blank init.pp file like:

class audit { }

Your best module layout inspiration should probably come from puppetlabs own forge modules. But how you write your manifests is pretty flexible. Just aim to be consistent :)

Does that mean the init.pp would call the other .PP files as I wanted them to be enabled or not?

See above, it depends on what you do. It now common to include parameter lookups in your class like so:

class audit (

 $some_var = 'some_default'

 $some_other = 'some_other'

) {

  ...some logic working on vars...

}

You can then abstract lookup data in things like hiera by setting 'audit::some_var: avalue' in your hiera data.

https://docs.puppetlabs.com/hiera/3.0/puppet.html

This also might be helpful in your considerations:

https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#appendix-smart-parameter-defaults 

HTH

Den

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJdJdQnn77Wz_NoAZMEhDt%3DeJoP6xUqng_EkmrRa96qPCGMPkg%40mail.gmail.com.

[warron.french]

Thanks Denmant.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/B20E9966-990B-4DF2-B53A-1377E942C856%40gmail.com.