Open Stack

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 
> <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
>
> -Dolph
>
>
> _______________________________________________
> 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/20131119/fe9077d8/attachment.html>