On Fri, May 20, 2016 at 5:52 PM, Jiri Tomasek <jtoma...@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.
Thanks,
--
Thomas
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
