Open Stack

On 15/11/13 21:06, Mike Spreitzer wrote:
> 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.

There was some discussion of this in different context here:

http://lists.openstack.org/pipermail/openstack-dev/2013-November/019316.html

What you're suggesting is not a terrible idea in general, but 
implementing it properly would be an even bigger departure from the way 
OpenStack does things than some other ideas that are already in the 
too-hard basket for departing too far from the way OpenStack does 
things. So I don't think it will work for this project.

>  > ... 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.

Yes, exactly. This was touched on only briefly in the thread[1], but 
IIRC there was some follow-up to this effect on IRC that you probably 
missed.

cheers,
Zane.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2013-November/019313.html