Open Stack

On 11/19/13 at 08:04pm, haruka tanizawa 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".

I'm working on the implementation of instance-tasks-api[0] in Nova and 
this is what I've been moving towards so far.  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?


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