Open Stack

Thank you for your reply.
I chould understand instance-tasks-api more clearly.


2013/12/4 Andrew Laski <andrew.laski at rackspace.com>

>
>  This is something that's entirely contained within Nova.  It's just
> adding a different representation of what is already occurring with
> task_states on an instance.
>
>
I've got it!



> I think it's better to think of it as a 'tag' field, not task_id.  task_id
> is something that would be generated within Nova, but a tag field would
> allow a client to specify a small amount of data to attach to the task.
>  Like a token that could be used to identify requests that have been made.
>  So if nothing is specified the field will remain blank.


Is getting task information(e.g. list tasks) API separated by each user?
Or can anybody execute these APIs?
Without user separated thought, user may not set unique id,
because there is a case that other user has already used this id.
This id doesn't work as an unique key of a request.



> 2013/11/28 Andrew Laski <andrew.laski at rackspa <andrew.laski at rackspace.com>
>>
>>> 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.
>>>
>>>
>>> Since task_id is auto generated, so I want to set unique string at 'tag'
field by myself.
(Maybe putting task_id by user his/her self is hard to accept?)
I want to use this field as judgement materials of retry(duplicate) request
or new request.
So, how about making this 'tag' field like flexible metadata field such as
other API(I don't know yet) can refer it.

Sincerely, Haruka Tanizawa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/0074e9d4/attachment.html>