Thanks Ben M. no worries. Anyones I see come by or while answering emails that don't have Fix Version I've been trying to guess what they are -- for things like this I'll set all to 0.13.0 then we can cherry pick to 0.12.0 ones that we want. I'll also continue working on pathology for 0.11.0.
Cheers! Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Benjamin Mahler <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Thursday, May 9, 2013 7:30 AM To: "[email protected]" <[email protected]> Subject: Re: [jira] [Updated] (MESOS-422) Master leader election should be more robust to stale ephemeral nodes >Hey Chris, we have prepared 0.12.0 for release but it's in the backlog >until the VOTE passes for 0.11.0. So any unfixed issues like this won't >land until 0.13.0 at the earliest unless we cherry-pick them. I was going >to update these but JIRA is down. =/ > >On Wed, May 8, 2013 at 11:43 PM, Chris A. Mattmann (JIRA) ><[email protected]>wrote: > >> >> [ >> >>https://issues.apache.org/jira/browse/MESOS-422?page=com.atlassian.jira.p >>lugin.system.issuetabpanels:all-tabpanel] >> >> Chris A. Mattmann updated MESOS-422: >> ------------------------------------ >> >> Fix Version/s: 0.12.0 >> >> - guess fix version >> >> > Master leader election should be more robust to stale ephemeral nodes >> > --------------------------------------------------------------------- >> > >> > Key: MESOS-422 >> > URL: https://issues.apache.org/jira/browse/MESOS-422 >> > Project: Mesos >> > Issue Type: Bug >> > Components: master >> > Reporter: Bill Farner >> > Assignee: Benjamin Mahler >> > Priority: Minor >> > Fix For: 0.12.0 >> > >> > >> > When a leading master exits abruptly, it may fatefully restart and >>think >> it's the leader. If particularly unlucky, this could result in a set of >> masters that are indefinitely unstable. >> > Sequence of events: >> > - Master process becomes leader >> > - Master process exits, session expiration counter begins >> > - Master process restarts, reads leader node contents, and decides >>it's >> the leader (based on PID equality) >> > - Previous master session expires, node is deleted >> > - Master decides a different master is leader, commits suicide >> > - Rinse, repeat for newly-created master node >> > The salient fact here is that leaders should be concerned with "did i >> create the leader node" (ignoring node data) while clients want to be >> apprised of leader's node data. >> > Relevant code: >> > >> >>https://github.com/apache/mesos/blob/trunk/src/detector/detector.cpp#L548 >> > ZK leader election recipe, for reference: >> > http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators >> For more information on JIRA, see: >>http://www.atlassian.com/software/jira >>
