previous behavior used class { 'stdlib::stages':} which isn't singleton and could cause duplication resource declaration on the stages class.
Since many community modules work by calling 'include stdlib' we should make stdlib's include of stages singleton as well.
Working with the stages in stdlib, I quickly ran into an issue where
most of the stages were before the main stage. This made it difficult
to declare any resources in a traditional "include" style class while
hiding the end user from the stages being associated with other module
classes.
For example, in class mcollective, a package would be declared in main.
However, if mcollective declared class mcollective::service in stage
infra_deploy and this was before main, there would be a dependency loop
between the package and the service.
There appears to be a convention around "chain your stages after main"
to avoid the need to create relatively empty shell classes.
Many modules I'm working on need a standard but
relatively granular location in the catalog. For example,
any module that configures the packaging system should
run "early"
Add the following stages which have inter-dependencies
in the top to bottom order listed:
* setup
* deploy
* runtime
* setup_infra
* deploy_infra
* main
* setup_app
* deploy_app
