Open Stack

On Tue, Oct 24, 2017 at 6:04 AM, Jiri Tomasek <jtomasek at redhat.com> wrote:
> Having a workflow which wraps whole deployment sounds great from the UI side
> too as it allows us to simplify the steps you described above. IIRC the
> reason the whole deployment did not get wrapped into a single workflow
> before is that the workflow/tasks timeouted before the deployment could
> finish which caused the workflow to fail.
>
> It should not be problematic to integrate these changes in GUI. The soon we
> can test it the better. As Brad noted, it is important to get as many Zaqar
> messages as possible so we can track the progress properly.

Thanks :). Sounds like at least the 3 of us, are in general agreement
about moving more towards wrapping all the deployment logic into a
single workflow, or as few workflows as possible. Doing so will reduce
the amount of logic we have to do client side and in the UI.

That being said...as I started to look in that direction, I realized
it is a lot of work to get us there, even if we did just enough to
support using config-download. I feel like such an effort should
probably be tracked in its own blueprint and properly scoped so that
the risk is well understood. I'd estimate it to be fairly disruptive
given the amount of changes needed in the clients and workflows.

To that end, I'm proposing we push such an effort off to Rocky, given
we already passed Queens-1.

For config-download for Queens, I've proposed the following as an
alternative solution:

https://review.openstack.org/#/c/514701/ (python-tripleoclient)
https://review.openstack.org/#/c/512876/ (tripleo-common)

I think it's fairly simple with low risk and it just follows the
existing pattern of calling an additional workflow to add
functionality. If we're happy with where we get to in queens with
config-download, we could consider making it the default.

-- 
-- James Slagle
--