6e9e838a0e
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.
42 lines
775 B
Puppet
42 lines
775 B
Puppet
# Class: stdlib::stages
|
|
#
|
|
# This class manages a standard set of Run Stages for Puppet.
|
|
#
|
|
# The high level stages are (In order):
|
|
#
|
|
# * setup
|
|
# * main
|
|
# * runtime
|
|
# * setup_infra
|
|
# * deploy_infra
|
|
# * setup_app
|
|
# * deploy_app
|
|
# * deploy
|
|
#
|
|
# Parameters:
|
|
#
|
|
# Actions:
|
|
#
|
|
# Declares various run-stages for deploying infrastructure,
|
|
# language runtimes, and application layers.
|
|
#
|
|
# Requires:
|
|
#
|
|
# Sample Usage:
|
|
#
|
|
# node default {
|
|
# include stdlib::stages
|
|
# class { java: stage => 'runtime' }
|
|
# }
|
|
#
|
|
class stdlib::stages {
|
|
|
|
stage { 'setup': before => Stage['main'] }
|
|
stage { 'runtime': require => Stage['main'] }
|
|
-> stage { 'setup_infra': }
|
|
-> stage { 'deploy_infra': }
|
|
-> stage { 'setup_app': }
|
|
-> stage { 'deploy_app': }
|
|
-> stage { 'deploy': }
|
|
|
|
}
|