<div dir="ltr"><div>Thank you for your reply.</div><div>I completely misunderstood.</div><div><br></div><div>>You're correct on request_id and task_id.</div><div>>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.</div>
<div>>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</div><div>>by checking if there's a task with that field set.</div><div>I see. </div>
<div>Especially, this point is so good.</div><div>'Heat could use it to ensure that they don't send requests twice by checking if there's a task with that field set.'</div><div><br></div><div>Moreover, I want to ask some questions about instance-tasks-api.</div>
<div>(I'm sorry it's a little bit long...)</div><div><br></div><div>* Is instance-tasks-api process outside of Nova? Is it standalone?</div><div>* About 'user can pass in with the request'</div><div> When user specifies task_id, task_id would be which user specified.</div>
<div> And if user doesn't specify task_id, does task_id generate automatically by Nova?</div><div> (like correlation_id is generated by oslo auto when specified from noonne.)</div><div>* About management state of API</div>
<div> Which is correct 'Queued, Active, Error, Complete' or ' pendig, in progress, and completed'?</div><div> And for exmple 'live migration', there are 'pre migration', 'migration(migrateToURI)' and 'post migration'.</div>
<div> Do you care about each detailed task? or care about 'live migrating ' ?</div><div> Does 'in progress'(for example) say about in progress of 'pre migration' or in progress of 'live migration'?</div>
<div>* About relation with 'Taskflow'.</div><div> Nova's taskflow-nize is not yet.</div><div> However, taskflow's persistence of flow state is good helper for cancelling tasks, I think.</div><div> (I think cancelling is not scope of i-2.)</div>
<div> How do you think of this relation and the fiture?</div><div><br></div><div>I would appriciate updating etherpad or blueprint if you have more detail </div><div>or data flow of instance-tasks-api.</div><div><br></div>
<div>Sincerely, Haruka Tanizawa</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/28 Andrew Laski <span dir="ltr"><<a href="mailto:andrew.laski@rackspace.com" target="_blank">andrew.laski@rackspace.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/22/13 at 10:14am, haruka tanizawa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for your reply.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm working on the implementation of instance-tasks-api[0] in Nova and<br>
</blockquote>
this is what I've been moving towards so far.<br>
Yes, I know. I think that is good idea.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The API will accept a string to be a part of the task but it will have<br>
</blockquote>
meaning only to the client, not to Nova. Then if >tasks can be searched or<br>
filtered by that field I think that would meet the requirements you layed<br>
out above, or is >something missing?<br>
Hmmm, as far as I understand, keystone(keystone work plan blueprint)<br>
generate request_id to each request.<br>
(I think that is a good idea.)<br>
And task_id is generated by instance-tasks-api.<br>
Is my understanding of this correct?<br>
Or if I miss something, thanks for telling me anything.<br>
</blockquote>
<br></div></div>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Haruka Tanizawa<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>