<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 20 May 2016 at 18:39, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 2016-05-20 at 17:52 +0200, Jiri Tomasek wrote:<br>
> Hey all,<br>
><br>
> I've been recently working on getting the TripleO UI integrated with<br>
> Zaqar, so it can receive a messages from Mistral workflows and act<br>
> upon them without having to do various polling hacks.<br>
><br>
> Since there is currently quite a large amount of new TripleO<br>
> workflows comming to tripleo-common, we need to standardize this<br>
> communication so clients can consume the messages consistently.<br>
><br>
> I'll try to outline the requirements as I see it to start the<br>
> discussion.<br>
><br>
> Zaqar queues:<br>
> To listen to the Zaqar messages it requires the client to connect to<br>
> Zaqar WebSocket, send authenticate message and subscribe to queue(s)<br>
> which it wants to listen to. The currently pending workflow patches<br>
> which send Zaqar messages [1, 2] expect that the queue is created by<br>
> client and name is passed as an input to the workflow [3].<br>
><br>
> From the client perspective, it would IMHO be better if all workflows<br>
> sent messages to the same queue and provide means to identify itself<br>
> by carrying workflow name and execution id. The reason is, that if<br>
> client creates a queue and triggers the workflow and then disconnects<br>
> from the Socket (user refreshes browser), then it does not know what<br>
> queues it previously created and which it should listen to. If there<br>
> is single 'tripleo' queue, then all clients always know that it is<br>
> where it will get all the messages from.<br>
<br>
</span>I think each workflow that supports queue messages (probably most of<br>
them) should probably allow to set your own queue_name that will get<br>
messages posted to it. Then it would simply be a convention that the<br>
client simply pass the same queue name to any concurrent workflows that<br>
are executed.<br>
<br>
The single queue -> multiple workflows use case is however important to<br>
support for the UI so adding the execution_id and fully qualified<br>
workflow name to each queue message should allow both patterns to work<br>
fine.<br>
<br>
And while the queue name is configurable perhaps we default it to<br>
'tripleo' so that you really don't have to set it anywhere unless you<br>
really want to.<br>
<br>
If you buy this I can update the patches linked below per the latest<br>
feedback.<br></blockquote><div><br></div><div>+1, I like this approach.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dan<br>
<span class=""><br>
<br>
><br>
> Messages identification and content:<br>
> The client should be able to identify message by it's name so it can<br>
> act upon it. The name should probably be relevant to the action or<br>
> workflow it reports on.<br>
><br>
> { <br>
>   body: {<br>
>     name: 'tripleo.validations.v1.run_validation,<br>
>     execution_id: '123123123'<br>
>     data: {}<br>
>   }<br>
> }<br>
><br>
> Other parts of the message are optional but it would be good to<br>
> provide information relevant to the message's purpose, so the client<br>
> can update relevant state and does not have to do any additional API<br>
> calls. So e.g. in case of running the validation a message includes<br>
> validation id.<br>
>  <br>
><br>
> [1] <a href="https://review.openstack.org/#/c/313953/2/workbooks/deployment.ya" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/313953/2/workbooks/deployment.ya</a><br>
> ml<br>
> [2] <a href="https://review.openstack.org/#/c/313632/8/workbooks/validations.y" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/313632/8/workbooks/validations.y</a><br>
> aml<br>
> [3] <a href="https://review.openstack.org/#/c/313957/1/tripleoclient/v1/overcl" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/313957/1/tripleoclient/v1/overcl</a><br>
> oud_execute.py<br>
><br>
> -- Jirka<br>
</span>> _____________________________________________________________________<br>
> _____<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubs" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubs</a><br>
> cribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>