[openstack-dev] [tripleo] Updates/upgrades equivalent for external_deploy_tasks
johfulto at redhat.com
Tue Jul 10 19:18:29 UTC 2018
On Tue, Jul 10, 2018 at 10:21 AM Jiří Stránský <jistr at redhat.com> wrote:
> 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
> optimize for.
> 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 :) ).
Thanks for thinking of this Jirka. I like option A and your WIP patch
(579170). As you say, it fits with what we're already doing and avoids
>  https://review.openstack.org/#/c/579170/
More information about the OpenStack-dev