<div dir="ltr">Hey all,<div><br></div><div>I've been recently working on getting the TripleO UI integrated with Zaqar, so it can receive a messages from Mistral workflows and act upon them without having to do various polling hacks.</div><div><br></div><div>Since there is currently quite a large amount of new TripleO workflows comming to tripleo-common, we need to standardize this communication so clients can consume the messages consistently.</div><div><br></div><div>I'll try to outline the requirements as I see it to start the discussion.</div><div><br></div><div>Zaqar queues:</div><div>To listen to the Zaqar messages it requires the client to connect to Zaqar WebSocket, send authenticate message and subscribe to queue(s) which it wants to listen to. The currently pending workflow patches which send Zaqar messages [1, 2] expect that the queue is created by client and name is passed as an input to the workflow [3].</div><div><br></div><div>From the client perspective, it would IMHO be better if all workflows sent messages to the same queue and provide means to identify itself by carrying workflow name and execution id. The reason is, that if client creates a queue and triggers the workflow and then disconnects from the Socket (user refreshes browser), then it does not know what queues it previously created and which it should listen to. If there is single 'tripleo' queue, then all clients always know that it is where it will get all the messages from.</div><div><br></div><div>Messages identification and content:</div><div>The client should be able to identify message by it's name so it can act upon it. The name should probably be relevant to the action or workflow it reports on.</div><div><br></div><div><font face="monospace, monospace">{ </font></div><div><font face="monospace, monospace">  body: {</font></div><div><font face="monospace, monospace">    name: 'tripleo.validations.v1.run_validation,</font></div><div><font face="monospace, monospace">    execution_id: '123123123'</font></div><div><font face="monospace, monospace">    data: {}</font></div><div><font face="monospace, monospace">  }</font></div><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">Other parts of the message are optional but it would be good to provide information relevant to the message's purpose, so the client can update relevant state and does not have to do any additional API calls. So e.g. in case of running the validation a message includes validation id.</font></div><div><span style="font-family:arial,helvetica,sans-serif"> </span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div>[1] <a href="https://review.openstack.org/#/c/313953/2/workbooks/deployment.yaml" target="_blank">https://review.openstack.org/#/c/313953/2/workbooks/deployment.yaml</a></div><div>[2] <a href="https://review.openstack.org/#/c/313632/8/workbooks/validations.yaml" target="_blank">https://review.openstack.org/#/c/313632/8/workbooks/validations.yaml</a></div><div>[3] <a href="https://review.openstack.org/#/c/313957/1/tripleoclient/v1/overcloud_execute.py" target="_blank">https://review.openstack.org/#/c/313957/1/tripleoclient/v1/overcloud_execute.py</a></div><div><br></div><div>-- Jirka</div></div>