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
>             }
>     }
>
> 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.

One more datapoint here. Ironic agreed on the following format:
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/notifications.html#proposed-change
but I'm not sure if we implemented it already.

>
> Thanks,
>