Page Comparison

...

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 that manage , 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 Boolean parameters $is_client and $is_server 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 

  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.