Open Stack

On 05/23/2016 11:51 AM, Dougal Matthews wrote:
>
>
> On 20 May 2016 at 18:39, Dan Prince <dprince at redhat.com 
> <mailto: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.
Sounds good to me too. Thanks!
>
>
>     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
>     <http://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     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

-- Jirka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160523/6b119657/attachment.html>