[openstack-dev] [TripleO] Deployment workflow changes for ui/client

Emilien Macchi emilien at redhat.com
Tue Oct 24 15:57:12 UTC 2017


On Tue, Oct 24, 2017 at 8:16 AM, James Slagle <james.slagle at gmail.com> wrote:
> 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.

+1, let's make iterations and config-download seems an excellent one.

> 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.

We'll give feedback in the review.

Thanks James for this update,
-- 
Emilien Macchi



More information about the OpenStack-dev mailing list