<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/19/2013 08:21 AM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gUSCidVy4_v_2ofvibwxRu2Cx3pQAKJvTnJ8+TskLmumA@mail.gmail.com"
type="cite">
<div dir="ltr">Related BP:
<div><br>
<div> Create a unified request identifier</div>
<div> <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/nova/+spec/cross-service-request-id">https://blueprints.launchpad.net/nova/+spec/cross-service-request-id</a></div>
</div>
</div>
</blockquote>
<br>
And we have discussed workplans as well, which would be data to be
carried along with the request id<br>
<br>
<a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/keystone/+spec/delegation-workplans">https://blueprints.launchpad.net/keystone/+spec/delegation-workplans</a><br>
<a class="moz-txt-link-freetext" href="https://etherpad.openstack.org/keystone_workplans">https://etherpad.openstack.org/keystone_workplans</a><br>
<br>
<blockquote
cite="mid:CAC=h7gUSCidVy4_v_2ofvibwxRu2Cx3pQAKJvTnJ8+TskLmumA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://review.openstack.org/#/c/29480/"
target="_blank">https://review.openstack.org/#/c/29480/</a><br>
[6] <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>