[openstack-dev] [Heat]Updated summit etherpad: API-retry-with-idempotency
Zane Bitter
zbitter at redhat.com
Mon Nov 18 12:11:44 UTC 2013
On 18/11/13 12:15, Mitsuru Kanabuchi wrote:
>
> On Fri, 15 Nov 2013 12:46:44 +0100
> Zane Bitter <zbitter at redhat.com> wrote:
>
>> Yes, but you don't know the UUID until you know it, and by then it's too
>> late (the resource has been created). So the idempotency token has to be
>> something passed in by the user.
>
> I completely agree with you that token has to be something passed in by
> the user.
>
>> You could allow the user to supply the UUID (you would obviously check
>> it for uniqueness). There is however, many possible ways in which that
>> could go horribly wrong (e.g. if you sharded based on UUID, an attacker
>> might be able to exploit that to overload one of your machines; the
>> uniqueness check leaks information from other tenants, &c.)
>
> Umm...
> Thank you for important comments.
>
> I understood your comment imply that idempotency token has to generate by
> trusted services. (e.g. keystone?)
The question from Chris implied that we could use the user-supplied
idempotency token as the ID of the resource. I don't believe there is a
safe way to do this.
> One of other hand, I'm thinking for easily way to implement idempotency token.
> In my idea, idempotency token has to:
>
> - be String (Don't use UUID)
> # for avoiding UUID generate problem
It can be a UUID (or anything), but you can't use it as the ID of the
resource.
> - isolate per tenant
> # for avoiding uniqueness check leaks
+1
> is appropriate. What do you think about that?
Yes, the implementation proposed in your blueprint[1] looks fine to me.
cheers,
Zane.
[1] https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token
More information about the OpenStack-dev
mailing list