[nova][heat][[keystone] RFC: introducing "request identification"

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[nova][heat][[keystone] RFC: introducing "request identification"

haruka tanizawa
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@.../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
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Dolph Mathews
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 <[hidden email]> 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@.../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
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

-Dolph

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Adam Young
On 11/19/2013 08:21 AM, Dolph Mathews wrote:
Related BP:

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 <[hidden email]> 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@.../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
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

-Dolph


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Ji2-3
Related BP:
In order to realize that she wanted to do it, in addition to the "included in the request a unique ID".
It seems that the ID is persisted as essential.
Including a unique ID in the request, it would be possible by cross-service-request-id.
just be output, cross-service-request-id will only be output to the log.
For administrators, that is so easy for reading log.
How about for user?
Can users check the status of the resource by ID?
I think it's difficult
Is it better to think of a combination of cross-service-request-id and TaskFlow?
You will be able to see what is done or doing by persisting cross-service-request-id using TaskFlow.


Yasunori Jitsukawa


2013/11/20 Adam Young <[hidden email]>
On 11/19/2013 08:21 AM, Dolph Mathews wrote:
Related BP:

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 <[hidden email]> 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@.../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
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

-Dolph


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Andrew Laski
In reply to this post by haruka tanizawa
On 11/19/13 at 08:04pm, haruka tanizawa 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".

I'm working on the implementation of instance-tasks-api[0] in Nova and
this is what I've been moving towards so far.  The API will accept a
string to be a part of the task but it will have meaning only to the
client, not to Nova.  Then if tasks can be searched or filtered by that
field I think that would meet the requirements you layed out above, or
is something missing?


>
>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@.../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
>[hidden email]
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

haruka tanizawa
Thanks for your reply.

>I'm working on the implementation of instance-tasks-api[0] in Nova and this is what I've been moving towards so far.
Yes, I know. I think that is good idea.

>The API will accept a string to be a part of the task but it will have meaning only to the client, not to Nova.  Then if >tasks can be searched or filtered by that field I think that would meet the requirements you layed out above, or is >something missing?
Hmmm, as far as I understand, keystone(keystone work plan blueprint) generate request_id to each request. 
(I think that is a good idea.)
And task_id is generated by instance-tasks-api.
Is my understanding of this correct?
Or if I miss something, thanks for telling me anything.

Haruka Tanizawa

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Mitsuru Kanabuchi
In reply to this post by Adam Young

On Tue, 19 Nov 2013 12:03:57 -0500
Adam Young <[hidden email]> 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 <[hidden email]
> > <mailto:[hidden email]>> 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@.../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
> >     [hidden email]
> >     <mailto:[hidden email]>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> >
> > -Dolph
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > [hidden email]
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--------------------
  Mitsuru Kanabuchi
    NTT Software Corporation
    E-Mail : [hidden email]


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Takahiro Shida
In reply to this post by haruka tanizawa

Hi all,

I'm also interested in this issue.

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

I checked this BP and the following review.
https://review.openstack.org/#/c/29480/

There are many comments. Finally, this review looks rejected by "user specified correlation-id" is useless and insecure.

>> 3. Enable keystone to generate "request identification" (we can call it 'request-token', for example).
> -2

So, this idea will be helpful to solve the "cross-service-request-id" problem.
Because the correlation-id specified by keystone.

How about nova guys and keystone guys ?



_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

haruka tanizawa
Hi, all!!
I've just summarized mail until now.


How to implement "request identification" ?
===============================================
1. Enable user to provide his/her own "request identification" within API request.
   e.g) Using instance-tasks-api
2. Use correlation_id in oslo as "request identification".
3. Enable keystone to generate "request identification" (we can call it 'request-token', for example).
   Like Keystone identifies 'User'.

Feedback
===============================================
There are already these blueprints.
* cross-service-request-id
* delegation-workplans
* instance-tasks-api

My conclusion
===============================================
However, the following opinions also have failed to resolve the problem what I want to solve.
1. Cross component
2. User can know before user put request API
3. User can see how their create request is going

* cross-service-request-id
-> Lack of point of 'User can know before user put request API'.
-> Or is something missing? Any plan?
* delegation-workplans
-> Lack of point of 'User can see how their create request is going'.
-> Does it return state of 'requests'?
* instance-tasks-api
-> Lack of point of 'User can know before user put request API'.
-> How do we know task_id when nova-api downs before we get task_id?

So, I think that 'Idempotency for OpenStack API'[0] is still valid because of requirement.
(Yes, I think word 'Idempotency' is appropriate...)

If you have any thoughts on that please share it with me.




2013/11/27 Takahiro Shida <[hidden email]>

Hi all,

I'm also interested in this issue.

I checked this BP and the following review.
https://review.openstack.org/#/c/29480/

There are many comments. Finally, this review looks rejected by "user specified correlation-id" is useless and insecure.


>> 3. Enable keystone to generate "request identification" (we can call it 'request-token', for example).
> -2

So, this idea will be helpful to solve the "cross-service-request-id" problem.
Because the correlation-id specified by keystone.

How about nova guys and keystone guys ?



_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Andrew Laski
In reply to this post by haruka tanizawa
On 11/22/13 at 10:14am, haruka tanizawa wrote:

>Thanks for your reply.
>
>>I'm working on the implementation of instance-tasks-api[0] in Nova and
>this is what I've been moving towards so far.
>Yes, I know. I think that is good idea.
>
>>The API will accept a string to be a part of the task but it will have
>meaning only to the client, not to Nova.  Then if >tasks can be searched or
>filtered by that field I think that would meet the requirements you layed
>out above, or is >something missing?
>Hmmm, as far as I understand, keystone(keystone work plan blueprint)
>generate request_id to each request.
>(I think that is a good idea.)
>And task_id is generated by instance-tasks-api.
>Is my understanding of this correct?
>Or if I miss something, thanks for telling me anything.

You're correct on request_id and task_id.  What I'm planning is a string
field that a user can pass in with the request and it will be part of
the task representation.  That field will have no meaning to Nova, but a
client like Heat could use it to ensure that they don't send requests
twice by checking if there's a task with that field set.

>
>Haruka Tanizawa

>_______________________________________________
>OpenStack-dev mailing list
>[hidden email]
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

haruka tanizawa
Thank you for your reply.
I completely misunderstood.

>You're correct on request_id and task_id.
>What I'm planning is a string field that a user can pass in with the request and it will be part of the task representation.
>That field will have no meaning to Nova, but a client like Heat could use it to ensure that they don't send requests twice
>by checking if there's a task with that field set.
I see. 
Especially, this point is so good.
'Heat could use it to ensure that they don't send requests twice by checking if there's a task with that field set.'

Moreover, I want to ask some questions about instance-tasks-api.
(I'm sorry it's a little bit long...)

* Is instance-tasks-api process outside of Nova? Is it standalone?
* About 'user can pass in with the request'
  When user specifies task_id, task_id would be which user specified.
  And if user doesn't specify task_id, does task_id generate automatically by Nova?
  (like correlation_id is generated by oslo auto when specified from noonne.)
* About management state of API
  Which is correct 'Queued, Active, Error, Complete' or ' pendig, in progress, and completed'?
  And for exmple 'live migration', there are 'pre migration', 'migration(migrateToURI)' and 'post migration'.
  Do you care about each detailed task? or care about 'live migrating ' ?
  Does 'in progress'(for example) say about in progress of 'pre migration' or in progress of 'live migration'?
* About relation with 'Taskflow'.
  Nova's taskflow-nize is not yet.
  However, taskflow's persistence of flow state is good helper for cancelling tasks, I think.
  (I think cancelling is not scope of i-2.)
  How do you think of this relation and the fiture?

I would appriciate updating etherpad or blueprint if you have more detail 
or data flow of instance-tasks-api.

Sincerely, Haruka Tanizawa


2013/11/28 Andrew Laski <[hidden email]>
On 11/22/13 at 10:14am, haruka tanizawa wrote:
Thanks for your reply.

I'm working on the implementation of instance-tasks-api[0] in Nova and
this is what I've been moving towards so far.
Yes, I know. I think that is good idea.

The API will accept a string to be a part of the task but it will have
meaning only to the client, not to Nova.  Then if >tasks can be searched or
filtered by that field I think that would meet the requirements you layed
out above, or is >something missing?
Hmmm, as far as I understand, keystone(keystone work plan blueprint)
generate request_id to each request.
(I think that is a good idea.)
And task_id is generated by instance-tasks-api.
Is my understanding of this correct?
Or if I miss something, thanks for telling me anything.

You're correct on request_id and task_id.  What I'm planning is a string field that a user can pass in with the request and it will be part of the task representation.  That field will have no meaning to Nova, but a client like Heat could use it to ensure that they don't send requests twice by checking if there's a task with that field set.


Haruka Tanizawa

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Adam Young
In reply to this post by Takahiro Shida
On 11/27/2013 12:45 AM, Takahiro Shida wrote:

Hi all,

I'm also interested in this issue.

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

I checked this BP and the following review.
https://review.openstack.org/#/c/29480/

There are many comments. Finally, this review looks rejected by "user specified correlation-id" is useless and insecure.

>> 3. Enable keystone to generate "request identification" (we can call it 'request-token', for example).

Lets not use the term Token.  Request Identifier is fine.

> -2

So, this idea will be helpful to solve the "cross-service-request-id" problem.
Because the correlation-id specified by keystone.

Can we make this "request envelope" so that we can put more information into the request than just an identifier?  Specifically, we are going to potentially want to put a set of trust Identifiers into a portion of the message to allow for secure delegation.


How about nova guys and keystone guys ?




_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

Andrew Laski
In reply to this post by haruka tanizawa
On 11/29/13 at 03:56pm, haruka tanizawa wrote:

>Thank you for your reply.
>I completely misunderstood.
>
>>You're correct on request_id and task_id.
>>What I'm planning is a string field that a user can pass in with the
>request and it will be part of the task representation.
>>That field will have no meaning to Nova, but a client like Heat could use
>it to ensure that they don't send requests twice
>>by checking if there's a task with that field set.
>I see.
>Especially, this point is so good.
>'Heat could use it to ensure that they don't send requests twice by
>checking if there's a task with that field set.'
>
>Moreover, I want to ask some questions about instance-tasks-api.
>(I'm sorry it's a little bit long...)
>
>* Is instance-tasks-api process outside of Nova? Is it standalone?

This is something that's entirely contained within Nova.  It's just
adding a different representation of what is already occurring with
task_states on an instance.

>* About 'user can pass in with the request'
>  When user specifies task_id, task_id would be which user specified.
>  And if user doesn't specify task_id, does task_id generate automatically
>by Nova?
>  (like correlation_id is generated by oslo auto when specified from
>noonne.)

I think it's better to think of it as a 'tag' field, not task_id.  
task_id is something that would be generated within Nova, but a tag
field would allow a client to specify a small amount of data to attach
to the task.  Like a token that could be used to identify requests that
have been made.  So if nothing is specified the field will remain blank.

>* About management state of API
>  Which is correct 'Queued, Active, Error, Complete' or ' pendig, in
>progress, and completed'?

The implementation hasn't reached this point yet so it's up for
discussion, but 'Queued, Active, Error, Complete' is the current plan.

>  And for exmple 'live migration', there are 'pre migration',
>'migration(migrateToURI)' and 'post migration'.
>  Do you care about each detailed task? or care about 'live migrating ' ?
>  Does 'in progress'(for example) say about in progress of 'pre migration'
>or in progress of 'live migration'?

I think it makes sense for live migration to be a task, and any
associated steps would be sub resources under that task.  When we start
to look at cancelling tasks it makes sense to cancel a live migration
rather than cancelling a pre migration.

>* About relation with 'Taskflow'.
>  Nova's taskflow-nize is not yet.
>  However, taskflow's persistence of flow state is good helper for
>cancelling tasks, I think.
>  (I think cancelling is not scope of i-2.)
>  How do you think of this relation and the fiture?

I think this is something to consider in the future.  For now I'm more
focused on the user visibility into tasks than how they're implemented
within Nova.  But there is a lot of implementation improvement that can
happen later.

>
>I would appriciate updating etherpad or blueprint if you have more detail
>or data flow of instance-tasks-api.
>
>Sincerely, Haruka Tanizawa
>
>
>2013/11/28 Andrew Laski <[hidden email]>
>
>> On 11/22/13 at 10:14am, haruka tanizawa wrote:
>>
>>> Thanks for your reply.
>>>
>>>  I'm working on the implementation of instance-tasks-api[0] in Nova and
>>>>
>>> this is what I've been moving towards so far.
>>> Yes, I know. I think that is good idea.
>>>
>>>  The API will accept a string to be a part of the task but it will have
>>>>
>>> meaning only to the client, not to Nova.  Then if >tasks can be searched
>>> or
>>> filtered by that field I think that would meet the requirements you layed
>>> out above, or is >something missing?
>>> Hmmm, as far as I understand, keystone(keystone work plan blueprint)
>>> generate request_id to each request.
>>> (I think that is a good idea.)
>>> And task_id is generated by instance-tasks-api.
>>> Is my understanding of this correct?
>>> Or if I miss something, thanks for telling me anything.
>>>
>>
>> You're correct on request_id and task_id.  What I'm planning is a string
>> field that a user can pass in with the request and it will be part of the
>> task representation.  That field will have no meaning to Nova, but a client
>> like Heat could use it to ensure that they don't send requests twice by
>> checking if there's a task with that field set.
>>
>>
>>> Haruka Tanizawa
>>>
>>
>>  _______________________________________________
>>> OpenStack-dev mailing list
>>> [hidden email]
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> [hidden email]
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>

>_______________________________________________
>OpenStack-dev mailing list
>[hidden email]
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [nova][heat][[keystone] RFC: introducing "request identification"

haruka tanizawa
Thank you for your reply.
I chould understand instance-tasks-api more clearly.


2013/12/4 Andrew Laski <[hidden email]>

This is something that's entirely contained within Nova.  It's just adding a different representation of what is already occurring with task_states on an instance.


I've got it!

 
I think it's better to think of it as a 'tag' field, not task_id.  task_id is something that would be generated within Nova, but a tag field would allow a client to specify a small amount of data to attach to the task.  Like a token that could be used to identify requests that have been made.  So if nothing is specified the field will remain blank.

Is getting task information(e.g. list tasks) API separated by each user?
Or can anybody execute these APIs?
Without user separated thought, user may not set unique id,
because there is a case that other user has already used this id.
This id doesn't work as an unique key of a request.

 
2013/11/28 Andrew Laski <[hidden email]
You're correct on request_id and task_id.  What I'm planning is a string
field that a user can pass in with the request and it will be part of the
task representation.  That field will have no meaning to Nova, but a client
like Heat could use it to ensure that they don't send requests twice by
checking if there's a task with that field set.


Since task_id is auto generated, so I want to set unique string at 'tag' field by myself.
(Maybe putting task_id by user his/her self is hard to accept?)
I want to use this field as judgement materials of retry(duplicate) request or new request.
So, how about making this 'tag' field like flexible metadata field such as
other API(I don't know yet) can refer it.

Sincerely, Haruka Tanizawa

_______________________________________________
OpenStack-dev mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev