summaryrefslogtreecommitdiffstats
path: root/manifests
diff options
context:
space:
mode:
authorEmilien Macchi <emilien@redhat.com>2016-01-15 19:25:17 -0500
committerJames Slagle <jslagle@redhat.com>2016-01-20 19:56:53 +0000
commit0543b4de44c36fcb351b127fa0c0d0c35d17965f (patch)
tree9fd5933155253bdf1ea9fe31b83c8bafd51ae7fe /manifests
parent69d44747ecd9f8fb0c171a7b533f8c3a81d89c5d (diff)
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
Diffstat (limited to 'manifests')
-rw-r--r--manifests/packages.pp15
1 files changed, 11 insertions, 4 deletions
diff --git a/manifests/packages.pp b/manifests/packages.pp
index c0971e9..5e111fa 100644
--- a/manifests/packages.pp
+++ b/manifests/packages.pp
@@ -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 <| |>
}