Related BP: Create a unified request identifier https://blueprints.launchpad.net/nova/+spec/cross-service-request-id
On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa <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 > 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