Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

StatusIN PROGRESS
StakeholdersChris Tessmer Kendall Moore Nicholas Markowski Judith Johnson 
Outcome
Due date
OwnerTrevor Vaughan 

Background

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

As we were working through issues regarding SIMP-57 - Getting issue details... STATUS , we started discussing how to bring additional consistency to our module footprint and make it easier to adopt across the board.

Our decision ended up being as follows.

Module Structure

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

  • module/manifests/
    • init.pp 
    • params.pp
    • install.pp
    • config.pp
    • service.pp
    • firewall.pp
    • 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)

Each of these items in bold must adhere to the following

  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 Structure

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

  • If the module has taken on too much responsibility for a single component, refactor it into separate component modules and use the recommended structure.
  • If the module manages a single responsibility yet is inherently complex, apply the recommended structure to appropriate areas.

Below are two recommended patterns for complex adaptations:

Modules that manage a client and server (a.k.a, related-but-asymmetric services)

For modules that manage 1..n related-but-assymetric services, create a namespace (directory) for each service and apply the basic structure to each namespace.  Use the top-level module structure to manage module-wide configurations and resource orderings.

For example, in a module 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 (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

NOTE: Many legacy modules will use an earlier client/server pattern in init.pp where the Boolean parameters $is_client and $is_server.  To maintain compatibility, keep the parameters in init.pp and .

Modules that manage their own internal "services"

Occasionally there may be a component (like ) that manages its own services.  

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  SIMP-20 - Getting issue details... STATUS  to adhere to this structure.
  • No labels