[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