Thank you for comments! On Thu, 14 Nov 2013 11:02:34 +1300 Steve Baker <sba...@redhat.com> wrote: > On 11/12/2013 07:40 PM, Mitsuru Kanabuchi wrote: > (snip) > Just to confirm, my understanding of the outcome of that session was > that pythonclients should implement retries of failed requests with the > idempotency token. > > Which means that no changes are required in heat, since the clients are > attempting the retries inside a single client call.
In my understand, the conclusion of summit discussion doesn't contain about implementation target(heat or pythonclient). I think, it needs more discussions. In my opinion, API-retry function should implement to heat for the following reasons. 1) Heat has to judge necessity of API-retry when Heat could get HTTP response. 2) (Mr.Zane commented) Heat has to delete underlying resource using idempotency key when POST retry-over happened. I think these processing(judge response code and cleanup resource) aren't pythonclient's work. What do you think? On Wed, 13 Nov 2013 23:19:00 +0100 Zane Bitter <zbit...@redhat.com> wrote: > (snip) > Assuming this can still fail eventually (even after retries) we still > need a way in Heat to make sure we can delete the resource by looking it > up from the idempotency token. > > Of course the idempotency token *should* be just the name, but since > most projects have inexplicably chosen not to enforce unique names (in > tenant scope), we're in the odd position of requiring 3 ways to look up > any resource (by name, UUID, and idempotency token). That's bonkers, but > what can you do? I agree with you. We don't want to add new look-up-keys if we could. Our objective is to solve the problem that is happen when API response is lost and Client doesn't get resource ID. Currently, parameters(uuid and name) aren't appropriate for the objective because these parameters can't get when API response was lost. There is no way to check resource existence from client side. I thought Client Token(Idempotency Token?) is best way to cope that circumstance. https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token This blueprint will provide us that Amazon like idempotency functionality. I really hope the blueprint's discussion will be active more. On Wed, 13 Nov 2013 16:35:15 -0600 Chris Friesen <chris.frie...@windriver.com> wrote: > On 11/13/2013 04:19 PM, Zane Bitter wrote: > (snip) > Why would the idempotency token not be the UUID? Presumably that should > be unique. I think so too, idempotency token have to be unique. In addition, the token would generated by each user. The idempotency token have to be unique per user for avoiding token conflict. Regards -------------------- 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