Open Stack

On Tue, Jul 10, 2018 at 10:22 AM Jiří Stránský <jistr at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180712/0ca65776/attachment.html>