[openstack-dev] [tripleo] Updates/upgrades equivalent for external_deploy_tasks
jistr at redhat.com
Tue Jul 10 14:20:55 UTC 2018
with the move to config-download deployments, we'll be moving from
executing external installers (like ceph-ansible) via Heat resources
encapsulating Mistral workflows towards executing them via Ansible
directly (nested Ansible process via external_deploy_tasks).
Updates and upgrades still need to be addressed here. I think we should
introduce external_update_tasks and external_upgrade_tasks for this
purpose, but i see two options how to construct the workflow with them.
During update (mentioning just updates, but upgrades would be done
analogously) we could either:
A) Run external_update_tasks, then external_deploy_tasks.
This works with the assumption that updates are done very similarly to
deployment. The external_update_tasks could do some prep work and/or
export Ansible variables which then could affect what
external_deploy_tasks do (e.g. in case of ceph-ansible we'd probably
override the playbook path). This way we could also disable specific
parts of external_deploy_tasks on update, in case reuse is undesirable
in some places.
B) Run only external_update_tasks.
This would mean code for updates/upgrades of externally deployed
services would be completely separated from how their deployment is
done. If we wanted to reuse some of the deployment tasks, we'd have to
use the YAML anchor referencing mechanisms. (&anchor, *anchor)
I think the options are comparable in terms of what is possible to
implement with them, the main difference is what use cases we want to
Looking at what we currently have in external_deploy_tasks (e.g.
), i think we'd have to do a lot of explicit reuse if we went with
B (inventory and variables generation, ...). So i'm leaning towards
option A (WIP patch at ) which should give us this reuse more
naturally. This approach would also be more in line with how we already
do normal updates and upgrades (also reusing deployment tasks). Please
let me know in case you have any concerns about such approach (looking
especially at Ceph and OpenShift integrators :) ).
More information about the OpenStack-dev