Hi Vinod, -----Original Message-----
From: Vinod Kone <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, May 10, 2013 9:09 AM To: "[email protected]" <[email protected]> Subject: Re: [jira] [Updated] (MESOS-422) Master leader election should be more robust to stale ephemeral nodes >I actually think it is more work to set a fix version when a bug is >reported. How is it more work than simply setting Fix Version to the current expected not-yet-released version? Then, if it ships later, the RM for release current=N, simply resets Fix Version to N+1 for that issue (and any others)? I'm not getting the more work thing. It's actually more work to go and do a pathology of what was committed when, and to maintain by-hand Change Logs, which would be auto generated by JIRA instead by simply setting a Fix Version and then tracking it with the issue throughout its lifecycle. >I personally would like a flow where we set "Affects version" >when the bug/issue is filed and "Fix version" when it is actually closed. I wasn't suggesting otherwise :) However, I would also suggest at a minimum setting Fix Version as well to current upcoming version to "collect" issues so that they appear in the Road Map setting for JIRA. This makes it easy to see what's scheduled for upcoming version X (==current version), and then decide if you are going to include issues A, B, .. , C in X or simply include certain ones in X, and bump others to X+1. >This way I don't have to do extra work during a release, to figure out >issues that had a fix version intended for that release but were never >went >into that release. I'm having to do extra work right now b/c Fix Version was never set and thus a CHANGELOG can't be automatically generated, and thus I have no clue what was part of 0.10.0. Furthermore, 0.9.0 was released with a CHANGELOG file that wasn't indicative of what changes actually went in (or at a minimum was grossly under specified). So all I'm asking is that folks spend a whole extra second or two adding the string ==current version for Fix Version when an issue is created. If you don't have the time, don't set it then, but I'm going to go through and set them all and try and get the pathology of a decent Roadmap/Changelog report in JIRA up and running. 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >On Thu, May 9, 2013 at 11:08 PM, Mattmann, Chris A (398J) < >[email protected]> wrote: > >> Hey Ben M., >> >> Thanks. My philosophy is that it's great to see a "Roadmap" report on >> JIRA which really shows what is coming up when. Also setting Fix Version >> initially indicates your "intended" but not "required" version where >> the fix will show up in (and makes generating .txt file CHANGELOG files >> a snap). >> >> So, I would say set it when the issue is created, and then if it changes >> and isn't cherry picked for that same version (and comes earlier or >>later) >> that's fine too. It's better to have some value. >> >> Fix version = what version you intend for the fix to be in. >> Affects version = the *released* version of the software where this >> bug/update/etc. >> applies to. >> >> HTH! >> >> 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 11:13 AM >> To: "[email protected]" <[email protected]> >> Subject: Re: [jira] [Updated] (MESOS-422) Master leader election should >>be >> more robust to stale ephemeral nodes >> >> >Great, should we only set 'Fix Version' when a fix is ready? There's >>also >> >'Affects Version' as well. >> > >> > >> >On Thu, May 9, 2013 at 10:44 AM, Mattmann, Chris A (398J) < >> >[email protected]> wrote: >> > >> >> 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 >> >> >> >> >> >> >> >> >>
