Open Stack

Thank you for comments!

On Thu, 14 Nov 2013 11:02:34 +1300
Steve Baker <sbaker at 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 <zbitter at 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.friesen at 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.mitsuru at po.ntts.co.jp