Open Stack

On 26/05/16 09:42, Dmitry Tantsur wrote:
> 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

That's a different thing - oslo.messaging notifications vs. Zaqar messages.

> but I'm not sure if we implemented it already.
>
>>
>> Thanks,
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev