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
This commit is contained in:
Steven Hardy 2017-01-30 10:20:32 +00:00
parent efa4c0ffd2
commit 1b58806a62
3 changed files with 16 additions and 14 deletions

@ -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:

@ -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
-----------------------------

@ -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]