> On Sept. 12, 2016, 10:57 a.m., Jiang Yan Xu wrote: > > include/mesos/mesos.proto, line 372 > > <https://reviews.apache.org/r/51803/diff/3/?file=1496755#file1496755line372> > > > > In genenal I think we should state "Feature X will be deprecated in > > version Y in favor of feature Z" to help folks understand the reasoning. In > > this case there happens to be difference of opinions on whether this > > feature/field should be deprecated in 2.0 (which we can discuss outside > > this review) but could you at least in this review add why this is > > deprecated and what do you recommend people to do when it is deprecated? > > haosdent huang wrote: > @xujyan, that requires we define the message to support HTTP health check > with statues. How about let me rephrase the comment here to describe it is > not supported and may be deprecated in Mesos 2.0? > > Jiang Yan Xu wrote: > I think the following statement is correct for 1.x, right? If so can we > use it? > > ``` > Expected response statuses. > NOTE: It is up to the custom executor to interpret and act on this field. > The default executors don't use this field and setting this field has no > effect on them (they interpret 2xx - 3xx as healthy). > ``` > > I understand that we are considering changing this but: > > - If it's unclear what we are going to do about it, is it worth > forewarning people about it going away? i.e., are you sure in the new design > it's going away? > - Do we know if this improvement is scheduled for after 2.0? i.e., not in > 1.x? > - We already have the TODO above, wouldn't it serve as a reminder that > we'll address this instead of a warning (which may unnecessarily freak > people out about an improvement that *may* not result in > backwards-incompatible API change? > > haosdent huang wrote: > hi, @xujyan As the reason I mentioned in > http://search-hadoop.com/m/0Vlr6lqzFSo3taf2 > > >IMO, if we sure a feature would be deprecated in Mesos 2.0, we should > deprecate it immediately although could not give a clear replacement at > that time. > Then users would think that feature is not recommended to use and avoid to > use it. > > I drop this. Please reopen it if you think it is still an issue.
My apologies. Sorry there's been offline chats and I was waiting for more comments on that thread. Let me circle back. However I still think we shouldn't do it so I am reopening the issue. @alexr could you follow up on the dev list? - Jiang Yan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/51803/#review148536 ----------------------------------------------------------- On Sept. 21, 2016, 11:21 a.m., haosdent huang wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/51803/ > ----------------------------------------------------------- > > (Updated Sept. 21, 2016, 11:21 a.m.) > > > Review request for mesos, Alexander Rukletsov, Joseph Wu, Silas Snider, and > Jiang Yan Xu. > > > Bugs: MESOS-6110 > https://issues.apache.org/jira/browse/MESOS-6110 > > > Repository: mesos > > > Description > ------- > > Ensured `HealthCheck::HTTPCheckInfo` compatible with the old one. > > > Diffs > ----- > > include/mesos/mesos.proto 2209ea2fb0bf39c773d60f8a0eea865320a03bb6 > include/mesos/v1/mesos.proto 00c623450268a990d48b4e119aa9429fabf2f135 > > Diff: https://reviews.apache.org/r/51803/diff/ > > > Testing > ------- > > > Thanks, > > haosdent huang > >
