Open Stack

On Thu, May 31, 2012, Mark McLoughlin <markmc at redhat.com> wrote:
> On Thu, 2012-05-31 at 08:58 -0700, Johannes Erdfelt wrote:
> > My XenAPI idempotency branch delays ACKs until after it's done
> > processing the message to ensure we get the message again after
> > restart.
> > 
> > https://review.openstack.org/#/c/7323
> > 
> > I can't say that I'm happy with the changes I've made to safely
> > support delayed ACKs. 
> 
> Starting an instance is a long running operation. We confirm its
> completion by updating the instance state in the DB. We could switch to
> casting "instance state change" messages instead.
> 
> Point is, I'd see an ack as "message received, I've acted on it" and
> handle the completion notification of long running messages separately.
> 
> Or put it another way, an ack for a long running operation is similar to
> "202 Accepted" in a REST API.

My only concern with this is that it pushes durability of the message
down a layer (assuming no orchestration).

It's probably unavoidable to maintain flexibility in the RPC layer, but
it does make things more complicated.

JE