Re: aurora watch_secs change

2014-12-18 Thread Kevin Sweeney
On Wed, Dec 17, 2014 at 4:33 PM, Maxim Khutornenko wrote: > > Here is in-person discussion follow up. Participants: Moses, wickman, > kevints, maxim. > > The proposal we came up with does not require implementing scheduler > health checks (AURORA-279). The idea is to require the executor to > move

Re: aurora watch_secs change

2014-12-18 Thread Nakamura
I think this approach is cleaner than relying on framework messages, and less fragile since we don't have to count on unreliable delivery. One other nice externality is that I always thought it was a little confusing that "RUNNING" happened before we were sure it was healthy. I think the new defi

Re: aurora watch_secs change

2014-12-18 Thread Brian Wickman
One nit: s/max_consecutive_successes/min_consecutive_successes/ This is "once the minimum number of consecutive passed health checks has been reached, transition to RUNNING." My take: I think this approach is strictly better than relying upon framework messages for correct update behavior. Lever

Re: aurora watch_secs change

2014-12-17 Thread Maxim Khutornenko
Here is in-person discussion follow up. Participants: Moses, wickman, kevints, maxim. The proposal we came up with does not require implementing scheduler health checks (AURORA-279). The idea is to require the executor to move a task from STARTING to RUNNING only when its health checks are satisfi

Re: aurora watch_secs change

2014-12-17 Thread Maxim Khutornenko
Resending as my original post got dropped somehow. Here is in-person discussion follow up. Participants: Moses, wickman, kevints, maxim. The proposal we came up with does not require implementing scheduler health checks (AURORA-279). The idea is to require the executor to move a task from STARTIN

Re: aurora watch_secs change

2014-12-13 Thread Nakamura
Hey, Just wanted to make sure my email didn't get lost in the cracks. As a reminder, the previous emails in this thread were: Bill Farner Br

Re: aurora watch_secs change

2014-12-04 Thread Nakamura
Hey, Sorry that this is replying to my own email, I didn't realize that I had to subscribe to the dev@aurora listserv to get updates. This email should really be in response to Brian Wickman's response. Hmm, I don't think only sending the transitions is sufficient though. My concern is that sin

Re: aurora watch_secs change

2014-12-02 Thread Brian Wickman
Refactoring the executor to allow (B) is also probably easiest, but per Farner's caveat -- it should only send framework messages on status transitions. There is something called the StatusManager that takes in input from any status checker (such as the health checker, announcer, resource manager,

Re: aurora watch_secs change

2014-12-02 Thread Bill Farner
Also relevant to this is AURORA-279, which suggests that we may not want to special-case the startup phase. Additional context - we should lean towards using mesos' framework messages as the communication medium. These messages are one-way, rather than request-response based. This seems to rule

aurora watch_secs change

2014-12-02 Thread Nakamura
Howdy, I'm interested in tackling AURORA-894, but I'm not terribly familiar with aurora, so I'd like some feedback on my design before I go forth. Bill pointed out that the hard bit would be designing the algorithm so it doesn't DDoS the scheduler, and I think I have an idea of the possible desig