Page Comparison

...

This is a record of the discussion on the 12th regarding the new layout of all SIMP Puppet Component Modules

As we were working through issues regarding

Our decision ended up being as follows.

Basic Module Structure

Our component modules will be patterned after the Puppet Labs suggested layout du jour. SIMP additions are in bold below.

...

1. They must be disabled by default
2. They must be name-based where the Boolean true and the Stringsimp amount to the same action.
3. They must allow for an ENC since we want maximum module uptake where possible

   1. This will look something like the following

      $enable_firewall = defined($::enable_firewall) ? $::enable_firewall : hiera('enable_firewall',false)

      1. Yes, this does mean that these features are disabled by default in the modules. However, they will be enabled by default in simp-core, so we're ensuring maximum safety for downstream users.
      2. Can we make this a function? Is that too much trouble/obfuscation?

Advanced Module Advanced Module Structure

Some modules may manage components that do not easily fit the recommended structure.  

...

Below are two recommended patterns for complex adaptations:

Modules that manage a client and

...

a server

This pattern applies to any module that manages multiple related-but-assymetric asymmetric services, such as a client and server.  

The general pattern is to:

• • create a namespace (directory) for each service

...

• • apply the basic structure to each namespace

...

• • continue to use the basic (top-level) module structure to manage module-wide configurations and resource orderings

...

For example, in a module like dhcp that manages both a client and server, introduce a server/ and client/ directory, and apply the recommended structure to each.

• module/manifests/
  • init.pp
  • params.pp, config.pp, etc (for module-wide settings)
  • server.pp
  • server/
    • params.pp
    • install.pp
    • config.pp
    • service.pp
    • firewall.pp
    • logging.pp
    • audit.pp
    • selinux.pp
  • client.pp
  • client/
    • params.pp
    • install.pp
    • config.pp
    • service.pp
    • firewall.pp
    • logging.pp
    • audit.pp
    • selinux.pp

...

Occasionally there may be a component (like xinted) that manages its own services.  multiple services of its own.  Managing these services 

• module/manifests/
  • init.pp
  • params.pp
  • config.pp
  • config/inet_service.pp  (a define that configures an inet_service)
  • service.pp
  • firewall.pp
  • firewall/inet_service.pp  (a define that establishes firewall rules for the inet_service)
    
  • logging.pp
  • audit.pp
  • selinux.pp (this one may just have to be mixed in at times, however, any boolean flipping should probably be done here)
    
    

Action Items

•  Discuss these decisions on Monday and ensure that I didn't miss anything of note. Update the page accordingly.
  
•  Construct the Puppet module skeleton defined in 

  Jira Legacy
  server JIRA (simp-project.atlassian.net) columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 45e63be1-2551-37a6-b050-86a38172f71d key SIMP-20

   to adhere to this structure.