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

diff --git a/manifests/packages.pp b/manifests/packages.pp
index c0971e9..5e111fa 100644 (file)
--- 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 <| |>
 
   }
 

diff --git a/spec/classes/tripleo_packages_spec.rb b/spec/classes/tripleo_packages_spec.rb
index 55a135b..80e5d7e 100644 (file)
--- a/spec/classes/tripleo_packages_spec.rb
+++ b/spec/classes/tripleo_packages_spec.rb
@@ -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