Controller: Exec puppet after all configuration

This patch adds a new ControllerNodesPostDeployment resource
which can be used along with the environment file to
specify a nested stack which is guaranteed to execute
after all the Controller config (HA, or other) have
executed.

This is really useful for Puppet in that Heat actually
controls where puppet executes in the deployment
process and we want to ensure puppet runs after
all hiera configuration data has be deployed to
the nodes. With the previous approach some of the
data would be there, but most of the HA data which
actually gets composed outside of the controller-puppet.yaml
nested stack would not be guaranteed to be there in time.

As os-apply-config (tripleo-image-elements) have their
ordering controlled within the elements themselves an empty stubbed
in nested stack has been added so that we don't break that
implementation.

Partial-bug: 1418805

Change-Id: Icd6b2c9c1f9b057c28649ee3bdce0039f3fd8422
This commit is contained in:
Dan Prince 2015-02-12 15:49:00 -05:00
parent 6b5ac01d2e
commit d25bd1f12e
6 changed files with 140 additions and 114 deletions

8
controller-post.yaml Normal file
View File

@ -0,0 +1,8 @@
heat_template_version: 2014-10-16
description: 'Controller Post Deployment'
# NOTE: this is a noop for os-apply-config style deployments because
# post deployment ordering is controlled by tripleo-image-elements
parameters:
servers:
type: json

View File

@ -6,6 +6,7 @@ resource_registry:
OS::TripleO::ObjectStorage: puppet/swift-storage-puppet.yaml
OS::TripleO::Net::SoftwareConfig: net-config-bridge.yaml
OS::TripleO::CephStorage: puppet/ceph-storage-puppet.yaml
OS::TripleO::ControllerPostDeployment: puppet/controller-post-puppet.yaml
# NOTE(dprince): requires a new release of python-heatclient
#default_parameters:

View File

@ -6,3 +6,4 @@ resource_registry:
OS::TripleO::ObjectStorage: swift-storage.yaml
OS::TripleO::Net::SoftwareConfig: net-config-noop.yaml
OS::TripleO::CephStorage: ceph-storage.yaml
OS::TripleO::ControllerPostDeployment: controller-post.yaml

View File

@ -816,6 +816,12 @@ resources:
config: {get_resource: allNodesConfig}
servers: {get_attr: [Compute, attributes, nova_server_resource]}
# Nested stack deployment runs after all other controller deployments
ControllerNodesPostDeployment:
type: OS::TripleO::ControllerPostDeployment
depends_on: [ControllerBootstrapNodeDeployment, ControllerAllNodesDeployment, ControllerSwiftDeployment]
properties:
servers: {get_attr: [Controller, attributes, nova_server_resource]}
outputs:
KeystoneURL:

View File

@ -0,0 +1,124 @@
heat_template_version: 2014-10-16
description: >
OpenStack controller node post deployment for Puppet.
parameters:
servers:
type: json
resources:
# NOTE(dprince): this example uses a composition class
# on the puppet side (loadbalancer.pp). This seemed like the
# cleanest way to encapulate the puppet resources definitions
# for HAProxy and Keepalived.
ControllerLoadbalancerPuppetConfig:
type: OS::Heat::SoftwareConfig
properties:
group: puppet
options:
enable_hiera: True
enable_facter: False
inputs:
- name: tripleo::loadbalancer::keystone_admin
default: true
- name: tripleo::loadbalancer::keystone_public
default: true
- name: tripleo::loadbalancer::neutron
default: true
- name: tripleo::loadbalancer::cinder
default: true
- name: tripleo::loadbalancer::glance_api
default: true
- name: tripleo::loadbalancer::glance_registry
default: true
- name: tripleo::loadbalancer::nova_ec2
default: true
- name: tripleo::loadbalancer::nova_osapi
default: true
- name: tripleo::loadbalancer::nova_metadata
default: true
- name: tripleo::loadbalancer::nova_novncproxy
default: true
- name: tripleo::loadbalancer::mysql
default: true
- name: tripleo::loadbalancer::rabbitmq
default: true
- name: tripleo::loadbalancer::swift_proxy_server
default: true
- name: tripleo::loadbalancer::ceilometer
default: true
- name: tripleo::loadbalancer::heat_api
default: true
- name: tripleo::loadbalancer::heat_cloudwatch
default: true
- name: tripleo::loadbalancer::heat_cfn
default: true
outputs:
- name: result
config:
get_file: manifests/loadbalancer.pp
ControllerLoadbalancerPuppetDeployment:
type: OS::Heat::SoftwareDeployments
properties:
name: puppet_1
servers: {get_param: servers}
config: {get_resource: ControllerLoadbalancerPuppetConfig}
ControllerPuppetConfig:
type: OS::Heat::SoftwareConfig
properties:
group: puppet
options:
enable_hiera: True
enable_facter: False
inputs:
- name: step
outputs:
- name: result
config:
get_file: manifests/overcloud_controller.pp
# Step through a series of Puppet runs using the same manifest.
# NOTE(dprince): Heat breakpoints would make for a really cool way to step
# through breakpoints in a controlled manner across the entire cluster
ControllerPuppetDeploymentServicesBase:
type: OS::Heat::StructuredDeployments
properties:
name: puppet_2
servers: {get_param: servers}
config: {get_resource: ControllerPuppetConfig}
input_values:
step: 1
actions: ['CREATE'] # no need for two passes on an UPDATE
ControllerRingbuilderPuppetConfig:
type: OS::Heat::SoftwareConfig
properties:
group: puppet
options:
enable_hiera: True
enable_facter: False
inputs:
outputs:
- name: result
config:
get_file: manifests/ringbuilder.pp
ControllerRingbuilderPuppetDeployment:
type: OS::Heat::StructuredDeployments
properties:
name: puppet_3
servers: {get_param: servers}
config: {get_resource: ControllerRingbuilderPuppetConfig}
ControllerPuppetDeploymentOvercloudServices:
type: OS::Heat::StructuredDeployments
properties:
name: puppet_4
servers: {get_param: servers}
config: {get_resource: ControllerPuppetConfig}
input_values:
step: 2

View File

@ -710,120 +710,6 @@ resources:
public_virtual_ip: {get_input: public_virtual_ip}
enable_package_install: {get_input: enable_package_install}
# NOTE(dprince): this example uses a composition class
# on the puppet side (loadbalancer.pp). This seemed like the
# cleanest way to encapulate the puppet resources definitions
# for HAProxy and Keepalived.
ControllerLoadbalancerPuppetConfig:
type: OS::Heat::SoftwareConfig
properties:
group: puppet
options:
enable_hiera: True
enable_facter: False
inputs:
- name: tripleo::loadbalancer::keystone_admin
default: true
- name: tripleo::loadbalancer::keystone_public
default: true
- name: tripleo::loadbalancer::neutron
default: true
- name: tripleo::loadbalancer::cinder
default: true
- name: tripleo::loadbalancer::glance_api
default: true
- name: tripleo::loadbalancer::glance_registry
default: true
- name: tripleo::loadbalancer::nova_ec2
default: true
- name: tripleo::loadbalancer::nova_osapi
default: true
- name: tripleo::loadbalancer::nova_metadata
default: true
- name: tripleo::loadbalancer::nova_novncproxy
default: true
- name: tripleo::loadbalancer::mysql
default: true
- name: tripleo::loadbalancer::rabbitmq
default: true
- name: tripleo::loadbalancer::swift_proxy_server
default: true
- name: tripleo::loadbalancer::ceilometer
default: true
- name: tripleo::loadbalancer::heat_api
default: true
- name: tripleo::loadbalancer::heat_cloudwatch
default: true
- name: tripleo::loadbalancer::heat_cfn
default: true
outputs:
- name: result
config:
get_file: manifests/loadbalancer.pp
ControllerLoadbalancerPuppetDeployment:
type: OS::Heat::SoftwareDeployment
properties:
name: puppet_1
server: {get_resource: Controller}
config: {get_resource: ControllerLoadbalancerPuppetConfig}
ControllerPuppetConfig:
type: OS::Heat::SoftwareConfig
properties:
group: puppet
options:
enable_hiera: True
enable_facter: False
inputs:
- name: step
outputs:
- name: result
config:
get_file: manifests/overcloud_controller.pp
# Step through a series of Puppet runs using the same manifest.
# NOTE(dprince): Heat breakpoints would make for a really cool way to step
# through breakpoints in a controlled manner across the entire cluster
ControllerPuppetDeploymentServicesBase:
type: OS::Heat::StructuredDeployment
properties:
name: puppet_2
server: {get_resource: Controller}
config: {get_resource: ControllerPuppetConfig}
input_values:
step: 1
actions: ['CREATE'] # no need for two passes on an UPDATE
ControllerRingbuilderPuppetConfig:
type: OS::Heat::SoftwareConfig
properties:
group: puppet
options:
enable_hiera: True
enable_facter: False
inputs:
outputs:
- name: result
config:
get_file: manifests/ringbuilder.pp
ControllerRingbuilderPuppetDeployment:
type: OS::Heat::StructuredDeployment
properties:
name: puppet_3
server: {get_resource: Controller}
config: {get_resource: ControllerRingbuilderPuppetConfig}
ControllerPuppetDeploymentOvercloudServices:
type: OS::Heat::StructuredDeployment
properties:
name: puppet_4
server: {get_resource: Controller}
config: {get_resource: ControllerPuppetConfig}
input_values:
step: 2
outputs:
ip_address:
description: IP address of the server in the ctlplane network