This workflow is no longer required becuase it has been converted to an
ansible playbook.
Story: 2007212
Task: 39045
Depends-On: I3d1c736f6d1ee704ece0101134f95582a5d060eb
Change-Id: I829217c99456f8ac8f49542eb1842c451fe77ad1
Signed-off-by: Kevin Carter <kecarter@redhat.com>
An execution state can go from RUNNING to SUCCESS between fetching the
last message from the websocket and polling the execution state. This
means the SUCCESS payload is never returned and the overcloud
deployment fails at the end with no indication as to why.
This change turns the output of the execution into the last payload,
allowing the calling SUCCESS logic to run.
Change-Id: Ic22021ba9a2717de199629e361c656e2f562fb38
Closes-Bug: #1842987
Serializing all the execution in a message can make the message too big.
This change was done in tripleo-common. this supports that change
This change still supports the old format and is backwards compatible.
Partial-Bug: #1812172
Change-Id: I40ee028366222f38f5ba1db58d171f98be75d009
The convention is to use the same queue name ("tripleo") for all
workflows. This can lead to messages showing from other tripleoclient
triggered workflows showing up during message polling if multiple
workflows are running at the same time.
This patch adds a check that will filter out any messages that do not
belong to the execution that is being waited on by comparing the
execution id with the root_execution_id returned in the execution
payload.
Depends-On: Icbe80c338d69efc6ce8fceb0f73f833bec588536
Change-Id: Ie6473d6a1044cdf76552d62645b4d63da2df9398
Related-Bug: #1794277
After fixing a bug with https://review.openstack.org/#/c/603802/ the
return introduced there is bogus, we have to raise a proper exception
and handle it like timeouts, to get all the mistral allright.
Change-Id: Idcdbd38129f5694c5452f3f8aca0388df80476b2
The result of syncrhonously called Mistral actions wasn't being checked
to see if the action passed or failed. The result is now checked and if
the action has failed, an exception will be raised.
Change-Id: I95ae8c98fec94cf91f3f209b593f6c1815729fd4
Closes-Bug: #1686811
Currently, tripleoclient will ignore messages from workflows if they
don't match the execution ID of the worflow it starts. This can happen
if the workflow starts sub-workflows, which run under their own
execution ID. tripleoclient will also stop listening for messages after
it recieves the first message from the workflow it started. Meaning, it
assumes the workflow to send one, and only one, message.
This change tackles the first limitation, by turning the message
consumption into a generator which yields each message one at a time.
It then starts a convention of assuming the workflow has finished if it
recieves a message with the top level execution ID and it contains a
status that isn't "RUNNING". For example: {"status": "SUCCESS"}.
Partial-Bug: #1646887
Change-Id: Ida07718b4fab41e0a6088f2db8f9b42b6fb09f72
Kevin Carter