Open Stack

On 05/25/2016 08:08 PM, Thomas Herve wrote:
> On Fri, May 20, 2016 at 5:52 PM, Jiri Tomasek <jtomasek at redhat.com> 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.
>>
>> 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.
> Hi,
>
> Sorry for not responding earlier, but I have some inputs. In Heat we
> publish events on Zaqar queue, and we defined this format:
>
>      {
>              'timestamp': $timestamp,
>              'version': '0.1',
>              'type': 'os.heat.event',
>              'id': $uuid,
>              'payload': {
>                  'XXX
>              }
>      }

Thanks, it totally makes sense. So when I convert my example to your 
usage it looks like this:

{
     body: {
         'timestamp': $timestamp,
         'type': 'tripleo.validations.v1.run_validation',
         'id': $uuid,
         'payload': {
             execution_id: '123123123',
             validation_id: '123321'
             ...
	 }
     }
}

I am not sure whether to separate the version from type as it would 
become complicated to reconstruct the workflow name (at least for 
tripleo workflows).
The most important is the 'type' as that is the key which we'd like to 
use on client to identify what action to take.

>
> I don't think we have strong requirements on that, and we can
> certainly make some tweaks. If we can converge towards something
> simimar that'd be great.
>
> Thanks,
>

Jirka