Open Stack

Related BP:

  Create a unified request identifier
  https://blueprints.launchpad.net/nova/+spec/cross-service-request-id

In order to realize that she wanted to do it, in addition to the "included
in the request a unique ID".
It seems that the ID is persisted as essential.
Including a unique ID in the request, it would be possible by
cross-service-request-id.
just be output, cross-service-request-id will only be output to the log.
For administrators, that is so easy for reading log.
How about for user?
Can users check the status of the resource by ID?
I think it's difficult
Is it better to think of a combination of cross-service-request-id and
TaskFlow?
You will be able to see what is done or doing by persisting
cross-service-request-id using TaskFlow.


Yasunori Jitsukawa


2013/11/20 Adam Young <ayoung at redhat.com>

>  On 11/19/2013 08:21 AM, Dolph Mathews wrote:
>
> Related BP:
>
>   Create a unified request identifier
>   https://blueprints.launchpad.net/nova/+spec/cross-service-request-id
>
>
> And we have discussed  workplans as well, which would be data to be
> carried along with the request id
>
> https://blueprints.launchpad.net/keystone/+spec/delegation-workplans
> https://etherpad.openstack.org/keystone_workplans
>
>
> On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa <harubelle at gmail.com>wrote:
>
>> Hi stackers!!
>>
>> I'd like to ask for your opinions about my idea of identifying request.
>>
>> Challenges
>> ==========
>>
>> We have no way to know the final result of an API request.
>> Indeed we can continuously get the status of allocated resources,
>> but this is just resource status, not request status.
>>
>> It doesn't matter so much for manual operations.
>> But it does for automated clients like heat.
>> We need request-oriented-status and it should be disclosed to clients.
>>
>> Literally, we need to address two items for it.
>>  1. how to identify request from clients
>>  2. how to disclose status of request to clients
>>
>> Note that this email includes only 1 for initiating the discussion.
>> Also, bp:instance-tasks-api[0] should include both two items above.
>>
>> Proposal: introducing "request identification"
>> =============================================
>>
>> I'd like to introduce "request identification", which is disclosed to
>> clients.
>> There are two characteristics:
>>
>>  - "request identification" is unique ID for each request
>>    so that we can identify tell a specific request from others.
>>  - "request identification" is available for clients
>>    so that we can enable any after-request-operations like check,
>> retry[1] or cancel[2].
>>    (of course we need to add more logic for check/retry/cancel,
>>     but I'm pretty sure that indentifying request is the starting point
>> for these features)
>>
>> In my understandings, main objections should be 'who should generate and
>> maintain such IDs?'.
>>
>> How to implement "request identification"
>> =========================================
>>
>> There are several options at least. (See also recent discussion at
>> openstack-dev[3])
>>
>> 1. Enable user to provide his/her own "request identification" within API
>> request.
>>    This should be the simplest way. But providing id from outside looks
>> hard to be accepted.
>>    For example, Idempotency for OpenStack API[4].
>>    Or instance-tasks-api enable to user to put his/her own "request
>> identification".
>>
>> 2. Use correlation_id in oslo as "request identification".
>>    correlation_id looks similar concept of "request indentification",
>>    but correlation_id in nova was already rejected[5].
>>
>> 3. Enable keystone to generate "request identification" (we can call it
>> 'request-token', for example).
>>    Before sending actual API request to nova-api, client sends a request
>> to keystone to get 'request-token'.
>>
>
>  -2
>
>
>>     Then client sends an actual API request with 'request-token'.
>>    Nova-api will consult it to keystone whether it was really generated.
>>    Sounds like a auth-token generated by keystone, differences are:
>>      [lifecycle] auth-token is used for multiple API requests before it
>> expires,
>>         'request-token' is used for only single API request.
>>      [reusing] if the same 'request-token' was specified twice or more
>> times,
>>         nova-api simply returns 20x (works like client token in AWS[6]).
>>         Keystone needs to maintain 'request-tokens' until they expire.
>>    For backward compatibility, actual API request without 'request-token'
>> should work as before.
>>    We can consider several options for uniqueness of 'request-token':
>>      uuid, any string with uniqueness per tennant, etc.
>>
>> IMO, since adding new implementation to Keystone is a little bit hard
>> work,
>> so implement of 1 is reasonable for me, just idea.
>>
>> Any comments will be appreciated.
>>
>> Sincerely, Haruka Tanizawa
>>
>> [0] https://blueprints.launchpad.net/nova/+spec/instance-tasks-api
>> [1] https://wiki.openstack.org/wiki/Support-retry-with-idempotency
>> [2] https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume
>> [3]
>> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09023.html
>> [4] https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token
>> [5] https://review.openstack.org/#/c/29480/
>> [6]
>> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Run_Instance_Idempotency.html
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>  --
>
>  -Dolph
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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/20131121/d0497113/attachment.html>