<tt><font size=2>Zane Bitter <zbitter@redhat.com> wrote on 11/14/2013
12:56:22 PM:<br>
<br>
> ...<br>
> My 2c: the way I designed the Heat API was such that extant stacks
can <br>
> be addressed uniquely by name. Humans are pretty good with names,
not so <br>
> much with 128 bit numbers. The consequences of this for the design
were:<br>
>   - names must be unique per-tenant<br>
>   - the tenant-id appears in the endpoint URL<br>
> <br>
> However, the rest of OpenStack seems to have gone in a direction where
<br>
> the "name" is really just a comment field, everything is
addressed only <br>
> by UUID. A consequence of this is that it renders the tenant-id in
the <br>
> URL pointless, so many projects are removing it.<br>
> <br>
> Unfortunately, one result is that if you create a resource and e.g.
miss <br>
> the Created response for any reason and thus do not have the UUID,
there <br>
> is now no safe, general automated way to delete it again. (There are
<br>
> obviously heuristics you could try.) To solve this problem, there
is a <br>
> proposal floating about for clients to provide another unique ID when
<br>
> making the request, which would render a retry of the request <br>
> idempotent. That's insufficient, though, because if you decide to
roll <br>
> back instead of retry you still need a way to delete using only this
ID.<br>
> <br>
> So basically, that design sucks for both humans (who have to remember
<br>
> UUIDs instead of names) and machines (Heat). However, it appears that
I <br>
> am in a minority of one on this point, so take it with a grain of
salt.<br>
</font></tt>
<br><tt><font size=2>I have been thinking about this too.  I tried
to convince my group that we should give up on assigning UUIDs in our system,
and rather make it the client's problem to assign the unique ID of what
corresponds to a Heat stack.  Just use one unique ID, supplied by
the client.  Simple, clean, and it hurts most peoples' heads.  Biggest
concern was: how are the clients going to be sure they do not mess up?
 That does not seem tough to me.  However, there is a less demanding
approach.  Introduce an operation in the API that allocates the stack's
unique ID.  It does nothing else for a stack, just returns the unique
ID.  If the reply makes it back into the client's persistent store,
all is well.  If not, the only thing that has been wasted is an ID;
an unused ID can be reaped after a satisfyingly long period of time ---
and if even that was too soon then the problem is easily detected and recovered
from.</font></tt>
<br>
<br><tt><font size=2><br>
> ... webhooks ...<br>
</font></tt>
<br><tt><font size=2>So if we want to do this right, it has to go something
like the following, right?  The client has to create a trust for the
thing that is going to invoke the webhook; using that, the webhook invocation
can be properly authorized.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>