Open Stack

On 05/20/2016 11:39 AM, Dan Prince wrote:
> 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

+1 as well. This seems reasonable.

-J


-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
openuc: +1.972.707.6408
mobile: +1.720.256.3933
Freenode: jrist
github/twitter: knowncitizen