maas-devel team mailing list archive

[Christian Robottom Reis <kiko@xxxxxxxxxxxxx>]

On Mon, Oct 20, 2014 at 11:34:56PM +0100, Gavin Panella wrote:
> The first WIP proposal [1] builds up a retry helper for serialization
> failures and integrates it into the `transactional` decorator.

I'd like to discuss wider the image of retrying as a global strategy for
dealing with serialization failures. I'll use a wiki edit as an analogy
to start with.

When a wiki edit conflicts, we do not automatically reset and retry
edits. The reason is that the correct resolution is normally to merge
changes; if you just clobbered one change with another, you end up
losing information or at least not allowing the opportunity to consider
what caused the conflicts.

In the MAAS case, here are two contrived examples:

    1. If we have two admins working together, one could be updating
       hostnames while the other setting up new credentials. In this
       case, I would expect the serialization failure to not be naïvely
       retried, but instead for the changes to be merged and then
       committed, possibly with user confirmation.

    2. If we have two admins working together, if both load pages at the
       same time and one changes a hostname to X and the other changes
       it to Y simultaneously, I would expect one of the transactions to
       fail with stale data.

Can anyone come up with other examples where retrying might be harmful?

I realize that optimistic concurrency does work for many use cases, but
for MAAS I'm not sure implementing it this way actually gets us to the
perfectly reliable system we aim for.
-- 
Christian Robottom Reis   | [+1] 612 888 4935    | http://launchpad.net/~kiko
Canonical VP Hyperscale   | [+55 16] 9 9112 6430 | http://async.com.br/~kiko