<div dir="ltr">Related BP:<div><br><div> Create a unified request identifier</div><div> <a href="https://blueprints.launchpad.net/nova/+spec/cross-service-request-id">https://blueprints.launchpad.net/nova/+spec/cross-service-request-id</a><div>
<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa <span dir="ltr"><<a href="mailto:harubelle@gmail.com" target="_blank">harubelle@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi stackers!!<br><br>I'd like to ask for your opinions about my idea of identifying request.<br>
<br>Challenges<br>==========<br><br>We have no way to know the final result of an API request.<br>Indeed we can continuously get the status of allocated resources,<br>
but this is just resource status, not request status.<br><br>It doesn't matter so much for manual operations.<br>But it does for automated clients like heat.<br>We need request-oriented-status and it should be disclosed to clients.<br>
<br>Literally, we need to address two items for it.<br> 1. how to identify request from clients<br> 2. how to disclose status of request to clients<br><br>Note that this email includes only 1 for initiating the discussion.<br>
Also, bp:instance-tasks-api[0] should include both two items above.<br><br>Proposal: introducing "request identification"<br>=============================================<br><br>I'd like to introduce "request identification", which is disclosed to clients.<br>
There are two characteristics:<br><br> - "request identification" is unique ID for each request<br> so that we can identify tell a specific request from others.<br> - "request identification" is available for clients<br>
so that we can enable any after-request-operations like check, retry[1] or cancel[2].<br> (of course we need to add more logic for check/retry/cancel,<br> but I'm pretty sure that indentifying request is the starting point for these features)<br>
<br>In my understandings, main objections should be 'who should generate and maintain such IDs?'.<br><br>How to implement "request identification"<br>=========================================<br><br>There are several options at least. (See also recent discussion at openstack-dev[3])<br>
<br>1. Enable user to provide his/her own "request identification" within API request.<br> This should be the simplest way. But providing id from outside looks hard to be accepted.<br> For example, Idempotency for OpenStack API[4].<br>
Or instance-tasks-api enable to user to put his/her own "request identification".<br><br>2. Use correlation_id in oslo as "request identification".<br> correlation_id looks similar concept of "request indentification",<br>
but correlation_id in nova was already rejected[5].<br><br>3. Enable keystone to generate "request identification" (we can call it 'request-token', for example).<br> Before sending actual API request to nova-api, client sends a request to keystone to get 'request-token'.<br>
</div></blockquote><div><br></div><div>-2</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
Then client sends an actual API request with 'request-token'.<br> Nova-api will consult it to keystone whether it was really generated.<br> Sounds like a auth-token generated by keystone, differences are:<br>
[lifecycle] auth-token is used for multiple API requests before it expires,<br> 'request-token' is used for only single API request.<br> [reusing] if the same 'request-token' was specified twice or more times,<br>
nova-api simply returns 20x (works like client token in AWS[6]).<br> Keystone needs to maintain 'request-tokens' until they expire.<br> For backward compatibility, actual API request without 'request-token' should work as before.<br>
We can consider several options for uniqueness of 'request-token':<br> uuid, any string with uniqueness per tennant, etc.<br><br>IMO, since adding new implementation to Keystone is a little bit hard work, <br>
so implement of 1 is reasonable for me, just idea.<br><br>Any comments will be appreciated.<br><br>Sincerely, Haruka Tanizawa<br><br>[0] <a href="https://blueprints.launchpad.net/nova/+spec/instance-tasks-api" target="_blank">https://blueprints.launchpad.net/nova/+spec/instance-tasks-api</a><br>
[1] <a href="https://wiki.openstack.org/wiki/Support-retry-with-idempotency" target="_blank">https://wiki.openstack.org/wiki/Support-retry-with-idempotency</a><br>[2] <a href="https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume" target="_blank">https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume</a><br>
[3] <a href="http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09023.html" target="_blank">http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09023.html</a><br>[4] <a href="https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token" target="_blank">https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token</a><br>
[5] <a href="https://review.openstack.org/#/c/29480/" target="_blank">https://review.openstack.org/#/c/29480/</a><br>[6] <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Run_Instance_Idempotency.html" target="_blank">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Run_Instance_Idempotency.html</a><br>
<br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div></div></div></div>