Open Stack

On Fri, 2016-05-20 at 17:52 +0200, Jiri Tomasek wrote:
> Hey all,
> 
> 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.
> 
> 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.
> 
> I'll try to outline the requirements as I see it to start the
> discussion.
> 
> Zaqar queues:
> 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].
> 
> 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.

I think each workflow that supports queue messages (probably most of
them) should probably allow to set your own queue_name that will get
messages posted to it. Then it would simply be a convention that the
client simply pass the same queue name to any concurrent workflows that
are executed.

The single queue -> multiple workflows use case is however important to
support for the UI so adding the execution_id and fully qualified
workflow name to each queue message should allow both patterns to work
fine.

And while the queue name is configurable perhaps we default it to
'tripleo' so that you really don't have to set it anywhere unless you
really want to.

If you buy this I can update the patches linked below per the latest
feedback.

Dan


> 
> Messages identification and content:
> 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.
> 
> { 
>   body: {
>     name: 'tripleo.validations.v1.run_validation,
>     execution_id: '123123123'
>     data: {}
>   }
> }
> 
> 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.
>  
> 
> [1] https://review.openstack.org/#/c/313953/2/workbooks/deployment.ya
> ml
> [2] https://review.openstack.org/#/c/313632/8/workbooks/validations.y
> aml
> [3] https://review.openstack.org/#/c/313957/1/tripleoclient/v1/overcl
> oud_execute.py
> 
> -- Jirka
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev