Example42 Puppet Modules goals | wish list

Example42 Puppet Modules are a work in progress, far from being completed.
Here's a list of the goals and the wish list for this project.

- Provide a coherent puppet environment
Paths, filenames, classnames and other elements have common structure. Logical, intuitive, simple.
Modules structure follows Reductive Labs and Puppet's community guidelines.
Modules names are application oriented ( apache, lighttpd ..)

- Modular, easy to use and integrate logic
Custom, re-usable application modules can be added.
A single project module cad define the infrastructure layout.
Existing configuration can be integrated in order to easily 'puppetize' an existing infrastructure.

- System Administrator oriented
Puppet code tends to be simple. General modules should not be customized.
Freedom to choose templates or static files
Easy importing of existing configuration files.
Stuff for sysadmins, not necessarily programmers.

- Live from scratch. Adapt according to custom needs
Modules work "out of the box" with default configurations
Customization and personalization should be easy and easily reusable.

- Cross Operating System
Support for different operative systems, versions and architectures.
Default values are Redhat based (work generally with Fedora and Centos).
Future planned support also for Debian, Solaris and FreeBSD .

- Fitting for heterogenous projects and network infrastructures
The logic of the infrastructure is defined in a single custom "project" module.
Here you define the logic that is more suitable to your infrastructure.

- Best practices references
Application installation and default configurations are oriented to best practices.
Subclasses are defined in order to use optimized configurations and extend standard functionalities.