<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 10, 2018 at 10:22 AM Jiří Stránský <<a href="mailto:jistr@redhat.com">jistr@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
with the move to config-download deployments, we'll be moving from <br>
executing external installers (like ceph-ansible) via Heat resources <br>
encapsulating Mistral workflows towards executing them via Ansible <br>
directly (nested Ansible process via external_deploy_tasks).<br>
<br>
Updates and upgrades still need to be addressed here. I think we should <br>
introduce external_update_tasks and external_upgrade_tasks for this <br>
purpose, but i see two options how to construct the workflow with them.<br>
<br>
During update (mentioning just updates, but upgrades would be done <br>
analogously) we could either:<br>
<br>
A) Run external_update_tasks, then external_deploy_tasks.<br>
<br>
This works with the assumption that updates are done very similarly to <br>
deployment. The external_update_tasks could do some prep work and/or <br>
export Ansible variables which then could affect what <br>
external_deploy_tasks do (e.g. in case of ceph-ansible we'd probably <br>
override the playbook path). This way we could also disable specific <br>
parts of external_deploy_tasks on update, in case reuse is undesirable <br>
in some places.<br>
<br>
B) Run only external_update_tasks.<br>
<br>
This would mean code for updates/upgrades of externally deployed <br>
services would be completely separated from how their deployment is <br>
done. If we wanted to reuse some of the deployment tasks, we'd have to <br>
use the YAML anchor referencing mechanisms. (&anchor, *anchor)<br>
<br>
I think the options are comparable in terms of what is possible to <br>
implement with them, the main difference is what use cases we want to <br>
optimize for.<br>
<br>
Looking at what we currently have in external_deploy_tasks (e.g. <br>
[1][2]), i think we'd have to do a lot of explicit reuse if we went with <br>
B (inventory and variables generation, ...). So i'm leaning towards <br>
option A (WIP patch at [3]) which should give us this reuse more <br>
naturally. This approach would also be more in line with how we already <br>
do normal updates and upgrades (also reusing deployment tasks). Please <br>
let me know in case you have any concerns about such approach (looking <br>
especially at Ceph and OpenShift integrators :) ).<br></blockquote><div><br></div><div>+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.</div><div>Some folks are currently working on extracting these tasks out of THT and I can already see something like:</div><div><br></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">        external_deploy_tasks</span><br></div><div><div>          - include_role:</div><div>              name: my-service</div><div>              tasks_from: deploy</div></div><div> </div><div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">        external_update_tasks</span><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div>          - include_role:</div><div>              name: my-service</div><div>              tasks_from: update</div><div><br></div><div>Or we could re-use the same playbooks, but use tags maybe.</div><div>Anyway, I like your proposal and I vote for option A.</div><div><br></div></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks<br>
<br>
Jirka<br>
<br>
[1] <br>
<a href="https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/docker/services/ceph-ansible/ceph-base.yaml#L340-L467" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/docker/services/ceph-ansible/ceph-base.yaml#L340-L467</a><br>
[2] <br>
<a href="https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/extraconfig/services/openshift-master.yaml#L70-L231" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/8d7525fdf79f915e3f880ea0f3fd299234ecc635/extraconfig/services/openshift-master.yaml#L70-L231</a><br>
[3] <a href="https://review.openstack.org/#/c/579170/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/579170/</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div>