Open Stack

On Tue, 19 Nov 2013 12:03:57 -0500
Adam Young <ayoung at redhat.com> wrote:

> On 11/19/2013 08:21 AM, Dolph Mathews wrote:
> > Related BP:
> >
> >   Create a unified request identifier
> > https://blueprints.launchpad.net/nova/+spec/cross-service-request-id

I interested in cross-service-request-id because it has potential to
solve several problem.

I believe that API-retry would improve reliability of processing
especially in HA environment.
But it has fundamental problem what POST methods isn't idempotent.
In my understand, currently, a lot of OpenStack API caller doesn't
API-retry to avoid problem when do POST and response was lost.

For reference:
  https://wiki.openstack.org/wiki/Support-retry-with-idempotency

I think id has to be something passed in by the client is essential
part of to solve that problem.
And I recently found that cross-service-request-id could realize
that objective. It is really nice idea.

I understand, currently cross-service-request-id's objective is for
debugging. It is very useful.
In addition, I think that cross-service-request-id can use for
ensuring POST idempotent.
If the service received known cross-service-request-id, the service
just return existence resource-id to clients.
And the service don't create new resource.

I understand it's need several considerations.
(Please refer the thread of
 [Heat]Updated summit etherpad: API-retry-with-idempotency)

However, basically it's good function for reliability.
What do you think about it?


> And we have discussed  workplans as well, which would be data to be 
> carried along with the request id
> 
> https://blueprints.launchpad.net/keystone/+spec/delegation-workplans
> https://etherpad.openstack.org/keystone_workplans
> 
> >
> > On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa <harubelle at gmail.com 
> > <mailto: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
> >     <mailto:OpenStack-dev at lists.openstack.org>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > -- 
> >
> > -Dolph
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--------------------
  Mitsuru Kanabuchi
    NTT Software Corporation
    E-Mail : kanabuchi.mitsuru at po.ntts.co.jp