On 11/22/13 at 10:14am, haruka tanizawa wrote:
Thanks for your reply.
I'm working on the implementation of instance-tasks-api[0] in Nova and
this is what I've been moving towards so far.
Yes, I know. I think that is good idea.
The API will accept a string to be a part of the task but it will have
meaning only to the client, not to Nova. Then if >tasks can be searched or
filtered by that field I think that would meet the requirements you layed
out above, or is >something missing?
Hmmm, as far as I understand, keystone(keystone work plan blueprint)
generate request_id to each request.
(I think that is a good idea.)
And task_id is generated by instance-tasks-api.
Is my understanding of this correct?
Or if I miss something, thanks for telling me anything.
You're correct on request_id and task_id. What I'm planning is a string
field that a user can pass in with the request and it will be part of
the task representation. That field will have no meaning to Nova, but a
client like Heat could use it to ensure that they don't send requests
twice by checking if there's a task with that field set.
Haruka Tanizawa
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
