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? * 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.) * 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.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