On Tue, 19 Nov 2013 12:03:57 -0500 Adam Young <ayo...@redhat.com> wrote:
> 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 I interested in cross-service-request-id because it has potential to solve several problem. I believe that API-retry would improve reliability of processing especially in HA environment. But it has fundamental problem what POST methods isn't idempotent. In my understand, currently, a lot of OpenStack API caller doesn't API-retry to avoid problem when do POST and response was lost. For reference: https://wiki.openstack.org/wiki/Support-retry-with-idempotency I think id has to be something passed in by the client is essential part of to solve that problem. And I recently found that cross-service-request-id could realize that objective. It is really nice idea. I understand, currently cross-service-request-id's objective is for debugging. It is very useful. In addition, I think that cross-service-request-id can use for ensuring POST idempotent. If the service received known cross-service-request-id, the service just return existence resource-id to clients. And the service don't create new resource. I understand it's need several considerations. (Please refer the thread of [Heat]Updated summit etherpad: API-retry-with-idempotency) However, basically it's good function for reliability. What do you think about it? > 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 -------------------- Mitsuru Kanabuchi NTT Software Corporation E-Mail : kanabuchi.mits...@po.ntts.co.jp _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
