packages: secure upgrade workflow from dependency cycles
Change the workflow to be: Upgrade all packages before any services that is notified & managed by Puppet. It also disable the Exec timeout so we rely on Heat timeout and not on the 300s that are the default in Puppet [1] Example: we upgrade and OpenStack config will change (obviously). Puppet catalog will contain 3 important things: * config resources * service resources * package-upgrade Exec resource with that patch, what will happen: * puppet will update config first or second and notify services * puppet will run package-upgrade first or second but before the package-upgrade Exec resource * at the very end, puppet will restart services That way, we avoid complications with Puppet dependency cycle issues. [1] https://docs.puppetlabs.com/references/latest/type.html#exec-attribute-timeout Closes-Bug: 1536349 Change-Id: I07310bdfc5b07b03ac9fa5f8c13e87eaa2bfef4d
This commit is contained in:
parent
69d44747ec
commit
0543b4de44
|
@ -58,12 +58,19 @@ class tripleo::packages (
|
|||
exec { 'package-upgrade':
|
||||
command => $pkg_upgrade_cmd,
|
||||
path => '/usr/bin',
|
||||
timeout => 0,
|
||||
}
|
||||
# A resource chain to ensure the upgrade ordering we want:
|
||||
# 1) upgrade puppet managed packages (will trigger puppet dependencies)
|
||||
# 2) then upgrade all packages via exec
|
||||
# 3) then restart services
|
||||
Package <| |> -> Exec['package-upgrade'] -> Service <| |>
|
||||
# 1) Upgrade all packages via exec.
|
||||
# Note: The Package Puppet resources can be managed after or before package-upgrade,
|
||||
# it does not matter. what we need to make sure is that they'll notify their
|
||||
# respective services (if they have ~> in their manifests or here with the ->)
|
||||
# for the other packages, they'll be upgraded before any Service notify.
|
||||
# This approach prevents from Puppet dependencies cycle.
|
||||
# 2) This upgrade will be run before any Service notified & managed by Puppet.
|
||||
# Note: For example, during the Puppet catalog, configuration will change for most of
|
||||
# the services so the Services will be likely restarted after the package upgrade.
|
||||
Exec['package-upgrade'] -> Service <| |>
|
||||
|
||||
}
|
||||
|
||||
|
|
|
@ -20,10 +20,7 @@ describe 'tripleo::packages' do
|
|||
shared_examples_for 'Red Hat distributions' do
|
||||
|
||||
let :pre_condition do
|
||||
"
|
||||
package{'nova-compute': ensure => present}
|
||||
service{'nova-compute': ensure => 'running'}
|
||||
"
|
||||
"service{'nova-compute': ensure => 'running'}"
|
||||
end
|
||||
|
||||
let :facts do
|
||||
|
@ -40,7 +37,6 @@ describe 'tripleo::packages' do
|
|||
end
|
||||
|
||||
it 'should contain correct upgrade ordering' do
|
||||
is_expected.to contain_package('nova-compute').that_comes_before('Exec[package-upgrade]')
|
||||
is_expected.to contain_exec('package-upgrade').that_comes_before('Service[nova-compute]')
|
||||
is_expected.to contain_exec('package-upgrade').with(:command => 'yum -y update')
|
||||
end
|
||||
|
|
Loading…
Reference in New Issue