Re: [openstack-dev] [Nova]Ideas of idempotentcy-client-token
Hi John I'm so sorry replying late to your message. However, to ensure the v3 API gets released in Icehouse, I would love to close the v2 API for changes, but perhaps I am being too harsh, and we should certainly only do that after the point where we promise not to back backwards in-compatible changes in the v3 API. John Yes. I think so, too. It depends on decision how to sort out v3 API. 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]Ideas of idempotentcy-client-token
On 30 October 2013 01:51, haruka tanizawa harube...@gmail.com wrote: Hi John! Thank you for your reply:) Sorry for inline comment. We also need something that doesn't clash with the cross-service request id, as that is doing something slightly different. Would idempotent-request-id work better? Oh, yes. Did you say about this BP( https://blueprints.launchpad.net/nova/+spec/cross-service-request-id )? (I am going to go that HK session.) So, I will user your opinion, and I try to go forward. Also, I assume we are only adding this into the v3 API? We should close the v2 API for additions I guess? Now I only adapt into v2 API, so it is aloso necessary to cope with the v3 API. Did I answer your question? We certainly need to add it into the v3 API, all new features must go there. However, to ensure the v3 API gets released in Icehouse, I would love to close the v2 API for changes, but perhaps I am being too harsh, and we should certainly only do that after the point where we promise not to back backwards in-compatible changes in the v3 API. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova]Ideas of idempotentcy-client-token
On Tue, 29 Oct 2013 10:32:18 + Joe Gordon joe.gord...@gmail.com wrote: * Can you fill out the questions found in http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ I guess, ClientToken(Idempotent) implementation is nice idea for API requester. In my opinion, after POST requested, A requester have to stop processing when it cannot get response, because requester doesn't know what the resouce created actually. In this case, retry is bad way, because it might cause create duplicate resources. I think, ClientToken provide the solution. If resource had been exist, It would skip resource creation by using ClientToken. A requester can avoid create duplicate resources using ClientToken in retry. I wish this blueprint would be implement. And I proposed related blueprint: https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency Regards On Tue, 29 Oct 2013 10:32:18 + Joe Gordon joe.gord...@gmail.com wrote: On Tue, Oct 29, 2013 at 8:50 AM, haruka tanizawa harube...@gmail.comwrote: Hi all! I proposed 'Idempotency for OpenStack API' as before. In this time, I rewrote BP( https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token ) and I implemented proto of it. I image below use-case. User can't know instance ID when the client has gone away before user get 'create server' response of request. So, User need to something which User can specify token like a mark. In the service, which can also be a problem of charging. In this case, idempotency client token is so useful. To specify the token itself by User, User can know status of server. How many times User put POST method, it is guaranteed the state of the POST which was same with return of User's first POST request. Moreover, I found that this BP( https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency) is based on my blueprint. If you have any idea about or question, please feel free to discuss anything. ** Also, I will attend HK summit. I like the idea but two comments: * Can you fill out the questions found in http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ * Can you break down the blueprint into work items, so we can see what steps are involved * Since this is for OpenStack APIs only the name client-token makes me think of keystone tokens, so I think we need a better name. Sincerely, Haruka Tanizawa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Mitsuru Kanabuchi NTT Software Corporation E-Mail : kanabuchi.mits...@po.ntts.co.jp ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova]Ideas of idempotentcy-client-token
Hi Mitsuru-san! Thank you for your comment. I guess, ClientToken(Idempotent) implementation is nice idea for API requester. In my opinion, after POST requested, A requester have to stop processing when it cannot get response, because requester doesn't know what the resouce created actually. In this case, retry is bad way, because it might cause create duplicate resources. Yes. It is that I really wanted to do. To tell the truth, I had several offline comments that the term idempotent is a little vague/ovrestate to describe what I want to achieve. To be more clear, this feature is to introduce an idea of Client Token in AWS to OpenStack. I think, ClientToken provide the solution. If resource had been exist, It would skip resource creation by using ClientToken. A requester can avoid create duplicate resources using ClientToken in retry. I wish this blueprint would be implement. And I proposed related blueprint: https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency I hope so :) Sincerely, Haruka Tanizawa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova]Ideas of idempotentcy-client-token
Hi all! I proposed 'Idempotency for OpenStack API' as before. In this time, I rewrote BP( https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token ) and I implemented proto of it. I image below use-case. User can't know instance ID when the client has gone away before user get 'create server' response of request. So, User need to something which User can specify token like a mark. In the service, which can also be a problem of charging. In this case, idempotency client token is so useful. To specify the token itself by User, User can know status of server. How many times User put POST method, it is guaranteed the state of the POST which was same with return of User's first POST request. Moreover, I found that this BP( https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency ) is based on my blueprint. If you have any idea about or question, please feel free to discuss anything. ** Also, I will attend HK summit. 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]Ideas of idempotentcy-client-token
Hi Joe! Thank you for your reply and sharing the information. I am going to rewrite blueprint from many point of view. Sincerely, Haruka Tanizawa 2013/10/29 Joe Gordon joe.gord...@gmail.com On Tue, Oct 29, 2013 at 8:50 AM, haruka tanizawa harube...@gmail.comwrote: Hi all! I proposed 'Idempotency for OpenStack API' as before. In this time, I rewrote BP( https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token ) and I implemented proto of it. I image below use-case. User can't know instance ID when the client has gone away before user get 'create server' response of request. So, User need to something which User can specify token like a mark. In the service, which can also be a problem of charging. In this case, idempotency client token is so useful. To specify the token itself by User, User can know status of server. How many times User put POST method, it is guaranteed the state of the POST which was same with return of User's first POST request. Moreover, I found that this BP( https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency) is based on my blueprint. If you have any idea about or question, please feel free to discuss anything. ** Also, I will attend HK summit. I like the idea but two comments: * Can you fill out the questions found in http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ * Can you break down the blueprint into work items, so we can see what steps are involved * Since this is for OpenStack APIs only the name client-token makes me think of keystone tokens, so I think we need a better name. Sincerely, 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]Ideas of idempotentcy-client-token
Hi Joe! Thank you for your help. I wrote BP https://blueprints.launchpad.net/nova/+spec/idempotentcy- client-token again. Could you review it when you have time. I like the idea but two comments: * Can you fill out the questions found in http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ * Can you break down the blueprint into work items, so we can see what steps are involved * Since this is for OpenStack APIs only the name client-token makes me think of keystone tokens, so I think we need a better name. About third point of this(about name), hmmm, I'm still thinking about it. How about 'Tracking-id'? 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]Ideas of idempotentcy-client-token
On 29 October 2013 11:56, haruka tanizawa harube...@gmail.com wrote: Hi Joe! Thank you for your help. I wrote BP https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token again. Could you review it when you have time. I like the idea but two comments: * Can you fill out the questions found in http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ * Can you break down the blueprint into work items, so we can see what steps are involved * Since this is for OpenStack APIs only the name client-token makes me think of keystone tokens, so I think we need a better name. About third point of this(about name), hmmm, I'm still thinking about it. How about 'Tracking-id'? We also need something that doesn't clash with the cross-service request id, as that is doing something slightly different. Would idempotent-request-id work better? Also, I assume we are only adding this into the v3 API? We should close the v2 API for additions I guess? John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova]Ideas of idempotentcy-client-token
Hi John! Thank you for your reply:) Sorry for inline comment. We also need something that doesn't clash with the cross-service request id, as that is doing something slightly different. Would idempotent-request-id work better? Oh, yes. Did you say about this BP( https://blueprints.launchpad.net/nova/+spec/cross-service-request-id )? (I am going to go that HK session.) So, I will user your opinion, and I try to go forward. Also, I assume we are only adding this into the v3 API? We should close the v2 API for additions I guess? Now I only adapt into v2 API, so it is aloso necessary to cope with the v3 API. Did I answer your question? Sincerely, Haruka Tanizawa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
