Re: Proposal: External Update Coordination

If the goal is to reduce complexity now and add features later, why not nuke both for now - kick off the update right away, and let lack of heartbeats serve as a uniform "unknown or unhealthy" signal? -=Bill On Mon, Oct 13, 2014 at 5:25 PM, Maxim Khutornenko wrote: > I am still +1 on the idea t

Re: Proposal: External Update Coordination

Pausing update on creation seems like a logical approach when dealing with inverted dependency model. I.e. updater is happy to act as long as it's greenlighted by the external signal. It's also aligned with a failover experience where coordinated updates are rehydrated in paused state waiting for H

Re: Proposal: External Update Coordination

I think waiting for the first heartbeat before taking any action is the simpler solution here as it allows the implementation to be entirely soft-state and still catches the bugs I described. The implementation is just PulseMonitorImpl - heartbeat calls pulse and mutation operations check isAlive.

Re: Proposal: External Update Coordination

I think waiting for the first heartbeat before taking any action is the simpler solution here as it allows the implementation to be entirely soft-state and still catches the bugs I described. The implementation is just PulseMonitorImpl - heartbeat calls pulse and mutation operations check isAlive.

Re: Proposal: External Update Coordination

Wait - simpler solution than what? We're talking about not doing either. -=Bill On Tue, Oct 14, 2014 at 12:16 PM, Kevin Sweeney wrote: > I think waiting for the first heartbeat before taking any action is the > simpler solution here as it allows the implementation to be entirely > soft-state a

Re: Proposal: External Update Coordination

I'm +1 for using lack of heartbeats as a uniform unknown-or-unhealthy signal, and punting on a more complex NACK signal (which we'd have to reliably persist). I think the only disagreement in this thread is whether the default state for a new update should be running or waiting-for-heartbeat. I th

Re: Proposal: External Update Coordination

I'm +1 for using lack of heartbeats as a uniform unknown-or-unhealthy signal, and punting on a more complex NACK signal (which we'd have to reliably persist). I think the only disagreement in this thread is whether the default state for a new update should be running or waiting-for-heartbeat. I th

Re: Proposal: External Update Coordination

I'm not arguing against the merits of the approach. Just feeling out whether that should be done _after_ the rest of the heartbeat support. Seems like it can be cleanly added at the end to get something usable earlier. -=Bill On Tue, Oct 14, 2014 at 12:38 PM, Kevin Sweeney wrote: > I'm +1 for

Jenkins build is back to normal : Aurora #644

See

Themes for Aurora documentation sprint

Hi all, Thanks for your interest in the documentation sprint so far, keep those tickets coming. Here are some themes I think we should address, if any of them interest you please volunteer by checking the JIRA Documentation compone