Replace common modules with community-maintained modules
Description
We currently maintain several component modules for which better alternatives exist on The Puppet Forge or in the wider Puppet community. In order to build a more robust product, to reduce SIMP maintenance load, and to better integrate and participate with the larger Puppet community, we should replace these existing SIMP modules with their third-party counterparts.
Before adopting a third-party module, we must ensure it meets our standards and requirements. The specifics of this will vary from module to module, but some things are common. (TODO: agree upon and formalize common SIMP standards and requirements for third-party modules)
Acceptance Criteria
Activity
Brain-dumping points from previous discussions on this topic (with bold keywords courtesy of RFC2119):
A third-party component module must be designed to either:
Â
work in concert with SIMP (e.g., accommodate SIMP's global catalysts)
provide sufficient class parameters to completely manage all of the SIMP-relevant configuration of the module's resources'
A third-party component module must not conflict with:
Other SIMP modules, classes, types, facts, or functions
Other SIMP dependencies when installed from the Forge
A third-party component module should:
Support all SIMP-supported OS "flavors"
Provide and pass working rspec-puppet spec tests for all SIMP-supported OS flavors
Provide and pass working beaker-rspec acceptance tests for all SIMP-supported OS flavors
For each third-party component module, a SIMP profile class should be constructed to provide SIMP-specific management and tests.
Any third-party module included with the "core" SIMP modules must have an "Approved" or "Supported" status on the Puppet Forge.
For non-"core" (e.g., unsupported) SIMP features, this requirement is optional.
Lucas Yamanishi, from the Big Ideas doc:
saz/sudo
In many environments sudo is a core feature of the OS. Given that Saz's module is the most downloaded on the Forge, having our own could be a blocker to adoption for a lot of people. Moreover, Saz's module is generally more flexible and, IMO, easier to understand than simp-sudo. We would also gain out-of-the-box compatibility with other distros.
On the downside, it doesn't support concat, so systems using older versions of sudo (those that don't support `#include`) would loose functionality. That's a pretty small subset of potential users, though-- RHEL 5 users, AFAIK.
example42/network
This one is mostly written by people other than Alessandro. He started it and remains the maintainer/merge master, but most of the big features and improvements have come from elsewhere.
It's main advantage over the Voxpupili module is that it manages state in addition to configuration. That is, it executes iputils, ifconfig, brctl, ifenslave, etc. rather than only editing files. This means small changes don't require a full interface down/up cycle.
It's also the Puppet, Inc. "approved" module for network configuration management.
Others
If there's a Puppet, Inc. "Supported" or "Approved" module on the Forge we should seriously consider using it. The stated policy of Puppet, Inc. is that only one module for any given component will ever get the "Approved" badge.
In regards to discussing advantages of network modules, keep in mind what we have planned in SIMP-1608.
