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:
parent
efa4c0ffd2
commit
1b58806a62
puppet
@ -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]
|
||||
|
Loading…
x
Reference in New Issue
Block a user