mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From haosdent huang <haosd...@gmail.com>
Subject Re: Review Request 51803: Ensured `HealthCheck::HTTPCheckInfo` compatible with the old one.
Date Thu, 22 Sep 2016 15:38:32 GMT


> On Sept. 12, 2016, 5:57 p.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?

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.


- haosdent


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51803/#review148536
-----------------------------------------------------------


On Sept. 21, 2016, 6:21 p.m., haosdent huang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51803/
> -----------------------------------------------------------
> 
> (Updated Sept. 21, 2016, 6:21 p.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