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 <harube...@gmail.com
<mailto:harube...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
-Dolph
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
