Open Stack

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.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[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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131129/87aaf7f0/attachment.html>