<div dir="ltr"><div dir="ltr"><div>On Tue, Dec 4, 2018 at 4:32 PM Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Would some of them be useful for fast forward upgrades in the future<br>
though? I suppose it all depends on where you draw your "upgrade lines"<br>
from major version to major version.<br>
</blockquote><div><br></div><div>AFIK these tasks aren't useful in master (Stein) for FFU, as they were used between Newton and Queens.</div><div>Since Queens only have containerized undercloud, and Undercloud isn't upgraded via FFU, I think these tasks could be removed.</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">
Many of these steps are very similar. It seems like it would be<br>
possible to detect podman in the systemd unit file (systemctl show<br>
<service> | grep podman) or something and then set your Ansible<br>
variables accordingly to disable the block if podman is being used.<br>
<br>
And improvement might be to put this logic into a playbook and consume<br>
it from each module. That is, if we even want to keep this upgrade code<br>
for the future.<br>
</blockquote></div><br clear="all"></div><div>Indeed, if upgrade team wants to keep  or refactor them [0], it's fine.<br></div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/582502">https://review.openstack.org/#/c/582502</a><br></div><div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div></div></div>