Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

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


2013/12/4 Andrew Laski andrew.la...@rackspace.com


  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 andrew.laski@rackspa andrew.la...@rackspace.com

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


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-12-03 Thread Adam Young

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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-12-03 Thread Andrew Laski

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 andrew.la...@rackspace.com


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




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-28 Thread 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 andrew.la...@rackspace.com

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



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-27 Thread 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.


Sincerely, Haruka Tanizawa

[0] https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token


2013/11/27 Takahiro Shida shida.takah...@gmail.com

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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-27 Thread Andrew Laski

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



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-26 Thread Takahiro Shida
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-22 Thread Mitsuru Kanabuchi

On Tue, 19 Nov 2013 12:03:57 -0500
Adam Young ayo...@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 harube...@gmail.com 
  mailto:harube...@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 

Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-21 Thread Andrew Laski

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



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-21 Thread 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-20 Thread Ji2-3
Related BP:

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

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 ayo...@redhat.com

  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


 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 harube...@gmail.comwrote:

 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] 

Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-19 Thread 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 harube...@gmail.comwrote:

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




-- 

-Dolph
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification

2013-11-19 Thread Adam Young

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


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 harube...@gmail.com 
mailto:harube...@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@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--

-Dolph


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org