Open Stack

Related BP:

  Create a unified request identifier
  https://blueprints.launchpad.net/nova/+spec/cross-service-request-id

On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa <harubelle at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131119/c732c754/attachment.html>