Related BP: Create a unified request identifier https://blueprints.launchpad.net/nova/+spec/cross-service-request-id
In order to realize that she wanted to do it, in addition to the "included in the request a unique ID". It seems that the ID is persisted as essential. Including a unique ID in the request, it would be possible by cross-service-request-id. just be output, cross-service-request-id will only be output to the log. For administrators, that is so easy for reading log. How about for user? Can users check the status of the resource by ID? I think it's difficult Is it better to think of a combination of cross-service-request-id and TaskFlow? You will be able to see what is done or doing by persisting cross-service-request-id using TaskFlow. Yasunori Jitsukawa 2013/11/20 Adam Young <ayo...@redhat.com> > 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>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 > listOpenStack-dev@lists.openstack.orghttp://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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
