[openstack-dev] [nova][heat][[keystone] RFC: introducing "request identification"
andrew.laski at rackspace.com
Tue Dec 3 18:36:30 UTC 2013
On 11/29/13 at 03:56pm, haruka tanizawa wrote:
>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?
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.
>* 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
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.
>* About management state of API
> Which is correct 'Queued, Active, Error, Complete' or ' pendig, in
>progress, and completed'?
The implementation hasn't reached this point yet so it's up for
discussion, but 'Queued, Active, Error, Complete' is the current plan.
> 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'?
I think it makes sense for live migration to be a task, and any
associated steps would be sub resources under that task. When we start
to look at cancelling tasks it makes sense to cancel a live migration
rather than cancelling a pre 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 think this is something to consider in the future. For now I'm more
focused on the user visibility into tasks than how they're implemented
within Nova. But there is a lot of implementation improvement that can
>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
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev