Open Stack

Zane Bitter <zbitter at redhat.com> wrote on 11/14/2013 12:56:22 PM:

> ...
> My 2c: the way I designed the Heat API was such that extant stacks can 
> be addressed uniquely by name. Humans are pretty good with names, not so 

> much with 128 bit numbers. The consequences of this for the design were:
>   - names must be unique per-tenant
>   - the tenant-id appears in the endpoint URL
> 
> However, the rest of OpenStack seems to have gone in a direction where 
> the "name" is really just a comment field, everything is addressed only 
> by UUID. A consequence of this is that it renders the tenant-id in the 
> URL pointless, so many projects are removing it.
> 
> Unfortunately, one result is that if you create a resource and e.g. miss 

> the Created response for any reason and thus do not have the UUID, there 

> is now no safe, general automated way to delete it again. (There are 
> obviously heuristics you could try.) To solve this problem, there is a 
> proposal floating about for clients to provide another unique ID when 
> making the request, which would render a retry of the request 
> idempotent. That's insufficient, though, because if you decide to roll 
> back instead of retry you still need a way to delete using only this ID.
> 
> So basically, that design sucks for both humans (who have to remember 
> UUIDs instead of names) and machines (Heat). However, it appears that I 
> am in a minority of one on this point, so take it with a grain of salt.

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.


> ... webhooks ...

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.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/d47eb112/attachment.html>