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.
I see.
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
by Nova?
(like correlation_id is generated by oslo auto when specified from
noonne.)
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
happen later.
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.la...@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[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
_______________________________________________
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
