[openstack-dev] [TripleO] Deployment workflow changes for ui/client
James Slagle
james.slagle at gmail.com
Thu Oct 19 20:56:12 UTC 2017
I've been looking at how we can hook up the deployment changes for
config-download[1] with the existing deployment workflows in Mistral.
However, it seems we have not sufficiently abstracted the logic to do
a "deployment" behind a given workflow(s). The existing things a
client (or UI) has to do is:
- call tripleo.deployment.v1.deploy_plan
- poll for success/failure of that workflow
- poll for success/failure of in progress Heat stack (list events, etc)
- call tripleo.deployment.v1.overcloudrc
(probably more things too)
If I want to make some changes to the deployment workflow, such that
after the Heat stack operation is complete, we run a config-download
action/workflow, then apply the generated ansible via
ansible-playbook, I can't really do that without requiring all clients
to also get updated to use those new steps (via calling new workflows,
etc).
As a first attempt, I took a shot at creating a workflow that does every step:
https://review.openstack.org/#/c/512876/
But even that will require client changes as it necessitates a
behavior change in that the workflow has to wait for the stack to be
complete as opposed to returning as soon as the stack operation is
accepted by Heat.
I'd like to implement this in a way that minimizes the impact of
changes on both python-tripleoclient and tripleo-ui, but it's looking
as if some changes would be required to use this new ansible driven
approach.
Thoughts or feedback on how to proceed? I'm guess I'm also wondering
if the existing API exposed by the workflows is easy to consume by the
UI, or if it would be better to be wrapped in a single workflow...at
least that way we could make logical implementation changes without
requiring ui/cilent changes.
[1] https://blueprints.launchpad.net/tripleo/+spec/ansible-config-download
--
-- James Slagle
--
More information about the OpenStack-dev
mailing list