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
