mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiang Yan Xu <...@jxu.me>
Subject Re: Review Request 51803: Ensured `HealthCheck::HTTPCheckInfo` compatible with the old one.
Date Thu, 22 Sep 2016 15:46:48 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message