Status
Stakeholders
Chris Tessmer Kendall Moore Nicholas Markowski Judith Johnson 
Outcome(Read the Background section)
Due date
Owner
Trevor Vaughan 


Background

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 , we started discussing how make our module collection more consistent and make it easier to adopt across the board.

Our decision ended up being as follows.

Basic Module Assumptions

Basic Module Structure

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

SIMP Subsystems

The bold files above correspond with optional security subsystems that SIMP can integrate with the module's resources. 

Standard Class Parameters in init.pp

Each module willl have the following class parameters in init.pp (when applicable):

Behavior of the Standard $simp_* Class Parameters

Each of the $simp_* parameters must adhere to the following:

  1. The parameter must be disabled (false) by default (NOTE: starting with SIMP 6).
  2. The parameter must honor booleans and Strings where the Boolean true and the String 'simp' amount to the same action.
    1. Welcome to the Trevorian type "Stroolean." (big grin)
    2. The String value such as 'simp' will translate into the filename in the subsystem  path simp/<subsystem>/simp.pp 
      1. This is intended to permit backwards compatibility between SIMP versions if they require mutually exclusive logic (i.e., 'simp', 'simp4', 'simp4_2', 'simp5', etc.,).
      2. QUESTION: what is the benefit of these files over the ::params pattern? 
        ANSWER: 
        1. it allows n parallel configuration tracks to coexist without conflicting
        2. it separates SIMP-specific settings from the rest of the module.
  3. The parameter must allow for an ENC or Hiera or straight parameter, since we want maximum module uptake where possible.

    1. This will look something like the following:

          $simp_firewall = defined('$::simp_opt::firewall') ? { true => getvar('::simp_opt::firewall'), default => hiera('simp_opt::firewall',true) }

      Note: When SIMP-1694 is complete, this will look like the following

          $simp_firewall = simp_opt('firewall', 'true')

      Translation:

          $parameter => { <if set> => <use global/ENV variable>, <otherwise> => <use what's in Hiera or default to true> }
      1. QUESTION: Should we make this defined->hiera->default logic a function in simplib?
        ANSWER: Yeah, probably. How about.....simp_def('variable','default')
      2. QUESTION: Why not just lookup()?
        ANSWER: lookup() was introduced in Puppet 4.  The core SIMP modules will need to support Puppet 3.x for at some time (at least another major version, probably longer).
  4. The default parameter lookup will reference the associated Global Catalyst.

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 several asymmetric services that must manage the same resources.

The general pattern is to:

Separate Client and Server Components (When NOT to apply this pattern)

In the case that you have a server and client that are two separately isolated services, such as the SSH server and client, then two separate modules should be created. This provides for a clean usage pattern over time.

Combined Client and Server Components (When TO apply this pattern)

There are going to be times where the server and client components cannot be split. A classic example is ntp, where the client and server require the same package and config file. 

In these cases, isolate the functionality within the module to the bests of your ability and repeat the pattern below each subdirectory segment.

As an example, you may use something like the following:

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 xinted) that manages multiple services of its own.  Managing these services 

Action Items