From 0543b4de44c36fcb351b127fa0c0d0c35d17965f Mon Sep 17 00:00:00 2001 From: Emilien Macchi Date: Fri, 15 Jan 2016 19:25:17 -0500 Subject: 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 --- manifests/packages.pp | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'manifests') 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 <| |> } -- cgit 1.2.3-korg