Open Stack

On 14/12/13 16:51, Jay Pipes wrote:

[snip]

> Instead of focusing on locking issues -- which I agree are very
> important in the virtualized side of things where resources are
> "thinner" -- I believe that in the bare-metal world, a more useful focus
> would be to ensure that the Tuskar API service treats related group
> operations (like "deploy an undercloud on these nodes") in a way that
> can handle failures in a graceful and/or atomic way.

Atomicity of operations can be achieved by intoducing critical sections.
You basically have two ways of doing that, optimistic and pessimistic.
Pessimistic critical section is implemented with a locking mechanism
that prevents all other processes from entering the critical section
until it is finished. Optimistic one is implemented using transactions,
that assume that there will be no conflict, and just rollback all the
changes if there was. Since none of OpenStack services that we use
expose any kind of transaction mechanisms (mostly, because they have
REST, stateless APIs, and transacrions imply state), we are left with
locks as the only tool to assure atomicity. Thus, your sentence above is
a little bit contradictory, advocating ignoring locking issues, and
proposing making operations atomic at the same time.
Perhaps you have some other way of making them atomic that I can't think of?

> For example, if the construction or installation of one compute worker
> failed, adding some retry or retry-after-wait-for-event logic would be
> more useful than trying to put locks in a bunch of places to prevent
> multiple sysadmins from trying to deploy on the same bare-metal nodes
> (since it's just not gonna happen in the real world, and IMO, if it did
> happen, the sysadmins/deployers should be punished and have to clean up
> their own mess ;)

I don't see why they should be punished, if the UI was assuring them
that they are doing exactly the thing that they wanted to do, at every
step, and in the end it did something completely different, without any
warning. If anyone deserves punishment in such a situation, it's the
programmers who wrote the UI in such a way.

-- 
Radomir Dopieralski