Open Stack

On 20 May 2016 at 18:39, Dan Prince <dprince at redhat.com> 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.
>

+1, I like this approach.


>
> 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
> > _____________________________________________________________________
> > _____
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160523/cce14a1f/attachment.html>