On Tue, Jul 10, 2018 at 10:22 AM Jiří Stránský <ji...@redhat.com> wrote:
> Hi, > > 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. > [1][2]), 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 [3]) 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 :) ). > +1 for Option A as well, I feel like it's the one which would give us the more of flexibility and also I'm not a big fan of the usage of Anchors for this use case. Some folks are currently working on extracting these tasks out of THT and I can already see something like: external_deploy_tasks - include_role: name: my-service tasks_from: deploy external_update_tasks - include_role: name: my-service tasks_from: update Or we could re-use the same playbooks, but use tags maybe. Anyway, I like your proposal and I vote for option A. > Thanks > > Jirka > > [1] > > https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/docker/services/ceph-ansible/ceph-base.yaml#L340-L467 > [2] > > https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/extraconfig/services/openshift-master.yaml#L70-L231 > [3] https://review.openstack.org/#/c/579170/ > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev