[openstack-dev] [nova][heat][[keystone] RFC: introducing "request identification"
harubelle at gmail.com
Fri Nov 29 06:56:18 UTC 2013
Thank you for your reply.
I completely misunderstood.
>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.
Especially, this point is so good.
'Heat could use it to ensure that they don't send requests twice by
checking if there's a task with that field set.'
Moreover, I want to ask some questions about instance-tasks-api.
(I'm sorry it's a little bit long...)
* Is instance-tasks-api process outside of Nova? Is it standalone?
* About 'user can pass in with the request'
When user specifies task_id, task_id would be which user specified.
And if user doesn't specify task_id, does task_id generate automatically
(like correlation_id is generated by oslo auto when specified from
* About management state of API
Which is correct 'Queued, Active, Error, Complete' or ' pendig, in
progress, and completed'?
And for exmple 'live migration', there are 'pre migration',
'migration(migrateToURI)' and 'post migration'.
Do you care about each detailed task? or care about 'live migrating ' ?
Does 'in progress'(for example) say about in progress of 'pre migration'
or in progress of 'live migration'?
* About relation with 'Taskflow'.
Nova's taskflow-nize is not yet.
However, taskflow's persistence of flow state is good helper for
cancelling tasks, I think.
(I think cancelling is not scope of i-2.)
How do you think of this relation and the fiture?
I would appriciate updating etherpad or blueprint if you have more detail
or data flow of instance-tasks-api.
Sincerely, Haruka Tanizawa
2013/11/28 Andrew Laski <andrew.laski at rackspace.com>
> On 11/22/13 at 10:14am, haruka tanizawa wrote:
>> Thanks for your reply.
>> I'm working on the implementation of instance-tasks-api 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
>> 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 at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev