Open Stack

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.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
>>

>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev