> On Oct. 26, 2016, 9:54 p.m., Jiang Yan Xu wrote: > > src/master/master.cpp, line 6047 > > <https://reviews.apache.org/r/53202/diff/1/?file=1546421#file1546421line6047> > > > > If neither of the above is true, can we log a warning? We recommend > > aganist this situation but in operations there's always possbility of > > straggler hosts. A warning would be helpful. > > Neil Conway wrote: > Logging a warning seems a bit ugly because it seems like an ad-hoc place > to put a version compatibility check; if we have N places in the code that > contain such warnings, it seems like it will be annoying to maintain and > result in ugly log output. > > I'd prefer to log a warning when an agent with an unsupported version > registers/re-registers with the master. > > Jiang Yan Xu wrote: > If we flat out reject connection from a component that doesn't meet the > version compatiblity requirement (a mechanism which we don't have today) and > log the client version and the reason for rejection there it would be clean, > but that's only one case. Since we are talking about a general vs. ad-hoc > place to put warnings, what happens with features we begin to deprecate but > are still in the deprecation window or those we clearly still need to support > but wish to give people heads-up about future deprecation, it is possible if > we do everything in one place? > > AFAIK we are currently just logging a warning when the code natrually > exercises the said logic, is this any different?
I think the question of deprecated features is a bit different. In this case, using a 0.28 agent with a 1.1 master is not supported; it _may_ work and probably will, but it would be good to educate users about that, rather than trying to track down specific situations in which 0.28 does something that is problematic. Anyway, I'm fine with adding a warning here, but it would be good to think about how we want to handle this in general. - Neil ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/53202/#review153950 ----------------------------------------------------------- On Oct. 26, 2016, 7:51 p.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/53202/ > ----------------------------------------------------------- > > (Updated Oct. 26, 2016, 7:51 p.m.) > > > Review request for mesos, Vinod Kone and Jiang Yan Xu. > > > Bugs: MESOS-6483 > https://issues.apache.org/jira/browse/MESOS-6483 > > > Repository: mesos > > > Description > ------- > > We don't guarantee compatibility with pre-1.0 agents. However, since it > is easy to avoid a CHECK failure in the master when an old agent > re-registers, it seems worth doing so. > > > Diffs > ----- > > src/master/master.cpp 23ddb995b4ad0fcdb589974308a2e81ececdad31 > > Diff: https://reviews.apache.org/r/53202/diff/ > > > Testing > ------- > > `make check` > > Disabled the code that fills-in `frameworks.recovered`; verified that > `PartitionTest.DisconnectedFramework` dies with a `CHECK` failure if this RR > is not applied but passes this with RR applied. > > > Thanks, > > Neil Conway > >
