On Tue, Oct 24, 2017 at 8:16 AM, James Slagle <james.sla...@gmail.com> wrote: > On Tue, Oct 24, 2017 at 6:04 AM, Jiri Tomasek <jtoma...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev