Reduce number of steps for upgrades

We don't need all the steps currently enabled for either batched
or concurrent updates, so decrease them.  In future we can perhaps
introspect the task tags during plan creation and set these
dynamically.

Change-Id: I0358886a332dfbecd03bc4a67086b08d25756c22
Partially-Implements: blueprint overcloud-upgrades-per-service

3 files changed, 16 insertions, 14 deletions

diff --git a/puppet/major_upgrade_steps.j2.yaml b/puppet/major_upgrade_steps.j2.yaml
index 00f863e4..88732f49 100644
--- a/puppet/major_upgrade_steps.j2.yaml
+++ b/puppet/major_upgrade_steps.j2.yaml
@@ -1,5 +1,6 @@
-{% set upgrade_steps_max = 8 -%}
 {% set enabled_roles = roles|rejectattr('disable_upgrade_deployment')|list -%}
+{% set batch_upgrade_steps_max = 3 -%}
+{% set upgrade_steps_max = 6 -%}
 heat_template_version: ocata
 description: 'Upgrade steps for all roles'
 
@@ -35,7 +36,7 @@ conditions:
 resources:
 
 # Upgrade Steps for all roles, batched updates
-{% for step in range(0, upgrade_steps_max) %}
+{% for step in range(0, batch_upgrade_steps_max) %}
   {% for role in roles %}
   # Step {{step}} resources
   {{role.name}}UpgradeBatchConfig_Step{{step}}:
@@ -97,7 +98,7 @@ resources:
       {% endfor %}
   {% else %}
       {% for dep in roles %}
-      - {{dep.name}}UpgradeBatch_Step{{upgrade_steps_max -1}}
+      - {{dep.name}}UpgradeBatch_Step{{batch_upgrade_steps_max -1}}
       {% endfor %}
   {% endif %}
     properties:
@@ -116,7 +117,7 @@ resources:
       {% endfor %}
   {% else %}
       {% for dep in roles %}
-      - {{dep.name}}UpgradeBatch_Step{{upgrade_steps_max -1}}
+      - {{dep.name}}UpgradeBatch_Step{{batch_upgrade_steps_max -1}}
       {% endfor %}
   {% endif %}
     properties:
diff --git a/puppet/services/README.rst b/puppet/services/README.rst
index 34cb350b..9c2d8c5c 100644
--- a/puppet/services/README.rst
+++ b/puppet/services/README.rst
@@ -57,10 +57,14 @@ is a list of ansible tasks to be performed during the upgrade process.
 
 Similar to the step_config, we allow a series of steps for the per-service
 upgrade sequence, defined as ansible tasks with a tag e.g "step1" for the first
-step, "step2" for the second, etc. Note that each step is performed in batches,
-then we move on to the next step which is also performed in batches (we don't
-perform all steps on one node, then move on to the next one which means you
-can sequence rolling upgrades of dependent services via the step value).
+step, "step2" for the second, etc (currently only two steps are supported, but
+more may be added when required as additional services get converted to batched
+upgrades).
+
+Note that each step is performed in batches, then we move on to the next step
+which is also performed in batches (we don't perform all steps on one node,
+then move on to the next one which means you can sequence rolling upgrades of
+dependent services via the step value).
 
 The tasks performed at each step is service specific, but note that all batch
 upgrade steps are performed before the `upgrade_tasks` described below.  This
@@ -93,9 +97,9 @@ step, "step2" for the second, etc.
 
    5) Perform any migration tasks, e.g DB sync commands
 
-   6) Start control-plane services
-
-   7) Any additional online migration tasks (e.g data migrations)
+Note that the services are not started in the upgrade tasks - we instead re-run
+puppet which does any reconfiguration required for the new version, then starts
+the services.
 
 Nova Server Metadata Settings
 -----------------------------
diff --git a/puppet/services/keystone.yaml b/puppet/services/keystone.yaml
index b989d502..7da4a9c2 100644
--- a/puppet/services/keystone.yaml
+++ b/puppet/services/keystone.yaml
@@ -313,8 +313,5 @@ outputs:
         - name: Sync keystone DB
           tags: step5
           command: keystone-manage db_sync
-        - name: Start keystone service (running under httpd)
-          tags: step6
-          service: name=httpd state=started
       metadata_settings:
         get_attr: [ApacheServiceBase, role_data, metadata_settings]