On 05/26/2016 12:18 PM, Thomas Herve wrote:
On Thu, May 26, 2016 at 11:48 AM, Jiri Tomasek <jtoma...@redhat.com> wrote:
On 05/25/2016 08:08 PM, Thomas Herve wrote:
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
}
}
Thanks, it totally makes sense. So when I convert my example to your usage
it looks like this:
{
body: {
'timestamp': $timestamp,
'type': 'tripleo.validations.v1.run_validation',
'id': $uuid,
'payload': {
execution_id: '123123123',
validation_id: '123321'
...
}
}
}
I am not sure whether to separate the version from type as it would become
complicated to reconstruct the workflow name (at least for tripleo
workflows).
The most important is the 'type' as that is the key which we'd like to use
on client to identify what action to take.
Looks great to me, thanks!
So as the workflows start to shape up and we start to use Zaqar messages
in clients, this is the mistral task we use to send a message:
send_message:
action: zaqar.queue_post
input:
queue_name: <% $.queue_name %>
messages:
body:
type: tripleo.baremetal.v1.register_or_update
execution_id: <% execution().id %>
payload:
status: <% $.get('status', 'SUCCESS') %>
message: <% $.get('message', '') %>
registered_nodes: <% $.registered_nodes or [] %>
I am coming to a conclusion, that instead of passing just the execution
ID, it would be much more beneficial to send the whole execution object,
because
1. the client is going to have to fire up additional request to get the
execution info
2. execution object itself often includes most of the information which
this task explicitly includes in payload
__________________________________________________________________________
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
