<div dir="ltr"><blockquote type="cite">
<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" target="_blank">https://blueprints.launchpad.net/nova/+spec/cross-service-request-id</a></div>
</div>
</div>
</blockquote>
In order to realize that she wanted to do it, in addition to the "included in the request a unique ID".<br>It seems that the ID is persisted as essential.<br>Including a unique ID in the request, it would be possible by cross-service-request-id.<br>
just be output, cross-service-request-id will only be output to the log.<br>For administrators, that is so easy for reading log.<br>How about for user?<br>Can users check the status of the resource by ID?<br>I think it's difficult<br>
Is it better to think of a combination of cross-service-request-id and TaskFlow?<br>You will be able to see what is done or doing by persisting cross-service-request-id using TaskFlow.<br><br><div class="gmail_extra"><br>
Yasunori Jitsukawa<br><br><br><div class="gmail_quote">2013/11/20 Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 11/19/2013 08:21 AM, Dolph Mathews
wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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 href="https://blueprints.launchpad.net/keystone/+spec/delegation-workplans" target="_blank">https://blueprints.launchpad.net/keystone/+spec/delegation-workplans</a><br>
<a href="https://etherpad.openstack.org/keystone_workplans" target="_blank">https://etherpad.openstack.org/keystone_workplans</a><br>
<br>
<blockquote 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 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:1px solid rgb(204,204,204);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:1px solid rgb(204,204,204);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" target="_blank">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"><span><font color="#888888">
<div><br>
</div>
-- <br>
<div><br>
</div>
-Dolph
</font></span></div><span><font color="#888888">
</font></span></div><span><font color="#888888">
</font></span></div><span><font color="#888888">
</font></span></div><span><font color="#888888">
</font></span></div><span><font color="#888888">
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</font></span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div></div>