Add support for update_tasks
These work the same way as upgrade_tasks *but* they use a step variable instead of tags, so we can iterate over a count/sequence which isn't possibly via a wrapper playbook with tags (we may want to align upgrade tasks with the same approach if this works out well). Note the tasks can be run via ansible-playbook on the undercloud, like: openstack overcloud config download --config-dir tmpconfig cd tmpconfig/tripleo-HCrDA6-config ansible-playbook -b -i /usr/bin/tripleo-ansible-inventory update_steps_playbook.yaml --limit controller The above will do a rolling update for the Controller role (note the inconsistent capitalization, we probably need to fix the group naming in tripleo-ansible-inventory) because we specify serial: 1 in the playbook. You can also trigger an update explicitly on one node like this, which is useful for debugging: ansible-playbook -vvv -b -i /usr/bin/tripleo-ansible-inventory update_steps_playbook.yaml --limit overcloud-controller-0 Change-Id: I20bb3e26ab9d9cadf1a31fd304de8a014a901aa9
This commit is contained in:
parent
46279be9cb
commit
1801565a75
|
@ -10,6 +10,7 @@
|
|||
{%- set primary_role_name = primary_role[0].name -%}
|
||||
# primary role is: {{primary_role_name}}
|
||||
{% set deploy_steps_max = 6 -%}
|
||||
{% set update_steps_max = 6 -%}
|
||||
|
||||
heat_template_version: pike
|
||||
|
||||
|
@ -319,4 +320,21 @@ outputs:
|
|||
with_sequence: count={{deploy_steps_max-1}}
|
||||
loop_control:
|
||||
loop_var: step
|
||||
update_steps_tasks: |
|
||||
{%- for role in roles %}
|
||||
- include: {{role.name}}/update_tasks.yaml
|
||||
when: role_name == '{{role.name}}'
|
||||
{%- endfor %}
|
||||
update_steps_playbook: |
|
||||
- hosts: overcloud
|
||||
serial: 1
|
||||
tasks:
|
||||
- include: update_steps_tasks.yaml
|
||||
with_sequence: count={{update_steps_max-1}}
|
||||
loop_control:
|
||||
loop_var: step
|
||||
- include: deploy_steps_tasks.yaml
|
||||
with_sequence: count={{deploy_steps_max-1}}
|
||||
loop_control:
|
||||
loop_var: step
|
||||
|
||||
|
|
|
@ -193,6 +193,16 @@ resources:
|
|||
expression: coalesce($.data, []).where($ != null).select($.get('upgrade_tasks')).where($ != null).flatten().distinct()
|
||||
data: {get_attr: [ServiceChain, role_data]}
|
||||
|
||||
UpdateTasks:
|
||||
type: OS::Heat::Value
|
||||
properties:
|
||||
type: comma_delimited_list
|
||||
value:
|
||||
yaql:
|
||||
# Note we use distinct() here to filter any identical tasks, e.g yum update for all services
|
||||
expression: coalesce($.data, []).where($ != null).select($.get('update_tasks')).where($ != null).flatten().distinct()
|
||||
data: {get_attr: [ServiceChain, role_data]}
|
||||
|
||||
UpgradeBatchTasks:
|
||||
type: OS::Heat::Value
|
||||
properties:
|
||||
|
@ -253,6 +263,7 @@ outputs:
|
|||
service_workflow_tasks: {get_attr: [ServiceWorkflowTasks, value]}
|
||||
step_config: {get_attr: [PuppetStepConfig, value]}
|
||||
upgrade_tasks: {get_attr: [UpgradeTasks, value]}
|
||||
update_tasks: {get_attr: [UpdateTasks, value]}
|
||||
upgrade_batch_tasks: {get_attr: [UpgradeBatchTasks, value]}
|
||||
service_metadata_settings: {get_attr: [ServiceServerMetadataHook, metadata]}
|
||||
|
||||
|
|
|
@ -155,7 +155,7 @@ 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.
|
||||
|
||||
Steps/tages correlate to the following:
|
||||
Steps/tags correlate to the following:
|
||||
|
||||
1) Stop all control-plane services.
|
||||
|
||||
|
@ -186,6 +186,18 @@ 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.
|
||||
|
||||
Update Steps
|
||||
------------
|
||||
|
||||
Each service template may optionally define a `update_tasks` key, which is a
|
||||
list of ansible tasks to be performed during the minor update process.
|
||||
|
||||
Similar to the upgrade_tasks, we allow a series of steps for the per-service
|
||||
update sequence, but note update_task selects the steps via a conditional
|
||||
referencing the step variable e.g when: step == 2, which is different to the
|
||||
tags based approach used for upgrade_tasks (the two may be aligned in future).
|
||||
|
||||
|
||||
Nova Server Metadata Settings
|
||||
-----------------------------
|
||||
|
||||
|
|
|
@ -56,3 +56,7 @@ outputs:
|
|||
- name: Update all packages
|
||||
tags: step3
|
||||
yum: name=* state=latest
|
||||
update_tasks:
|
||||
- name: Update all packages
|
||||
yum: name=* state=latest
|
||||
when: step == "3"
|
||||
|
|
Loading…
Reference in New Issue