Open Stack

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'.
   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131119/4aeeb3c5/attachment.html>