On 15/11/13 21:06, Mike Spreitzer wrote:
Zane Bitter <zbit...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
