Aaron—
we do use some on Boost libraries.
I think supporting HTTP/2 is a great idea and we should definitely create a
JIRA epic to evaluate and track work. My intuition we will have to
implement it ourselves in libprocess. Would you like to open a ticket?
However, let's not hijack this thread for this : ).
Everyone, are there any Mesos users with custom executors which use HTTP
part of HealthCheck protobuf?
On Fri, Sep 2, 2016 at 6:49 PM, Aaron Wood <aaronjw...@gmail.com> wrote:
> That's great!
>
> I would be interested in seeing support for HTTP/2 as I think the benefits
> of header compression and connection multiplexing could provide some nice
> improvements in certain environments.
>
> What do you (or anyone else here) think about this? There's no use of Boost
> anywhere in this project, right? I'm not sure what good libraries there are
> to provide this for C++ 11.
>
> On Fri, Sep 2, 2016 at 12:46 PM, haosdent <haosd...@gmail.com> wrote:
>
> > Just test with curl 7.50.1, HTTP 2 is supported.
> >
> > On Sat, Sep 3, 2016 at 12:32 AM, haosdent <haosd...@gmail.com> wrote:
> >
> > > The current implementation of HTTP(s) health check is based on curl.
> > > According to the document of curl
> > >
> > > >Since 7.47.0, the curl tool enables HTTP/2 by default for HTTPS
> > > connections.
> > >
> > > So I think it should be supported if the curl version in your Mesos
> Agent
> > > is higher that 7.47. But I have not yet try this.
> > >
> > > On Sat, Sep 3, 2016 at 12:23 AM, Aaron Wood <aaronjw...@gmail.com>
> > wrote:
> > >
> > >> Since you mentioned that you're working on supporting HTTPS health
> > checks
> > >> I'm curious if there are any plans to support HTTP/2 over TLS (or even
> > >> over
> > >> plain HTTP). I would think that using HTTP/2 for any communication
> that
> > >> happens in Mesos would provide a nice improvement in heavy load
> > >> situations.
> > >>
> > >> On Fri, Sep 2, 2016 at 10:59 AM, haosdent <haosd...@gmail.com> wrote:
> > >>
> > >> > Hi, dear friends. @alexr and I are working on supporting HTTP(s)/TCP
> > >> Health
> > >> > Check in Mesos.
> > >> > We have finished and committed some initial works. But if you use
> the
> > >> old
> > >> > protobuf definition of
> > >> > `HealthCheck` to implement HTTP health check in your custom executor
> > >> > before, our changes recently would
> > >> > break it.
> > >> >
> > >> > The change of the protobuf definition of `HealthCheck` is
> > >> >
> > >> > ```
> > >> > message HealthCheck {
> > >> > + enum Type {
> > >> > + UNKNOWN = 0;
> > >> > + COMMAND = 1;
> > >> > + HTTP = 2;
> > >> > + TCP = 3;
> > >> > + }
> > >> > +
> > >> > - message HTTP {
> > >> > + message HTTPCheckInfo {
> > >> > + optional string scheme = 1;
> > >> > - required uint32 port = 1;
> > >> > + required uint32 port = 2;
> > >> > - optional string path = 2 [default = "/"];
> > >> > + optional string path = 3;
> > >> > - repeated uint32 statuses = 4;
> > >> > }
> > >> > ...
> > >> > + optional Type type = 8;
> > >> > - // HTTP health check - not yet recommended for use, see
> > MESOS-2533.
> > >> > - optional HTTP http = 1;
> > >> > + optional HTTPCheckInfo http = 1;
> > >> > ...
> > >> > }
> > >> > ```
> > >> >
> > >> > Noted that we add a field `type` to specific the health check type
> and
> > >> use
> > >> > `HTTPCheckInfo` instead of `HTTP`.
> > >> > As I know, Mesos didn't support HTTP health check before 1.0 and it
> is
> > >> > supposed to not used.
> > >> >
> > >> > But thanks to @swsnider to report the issues recently, user may
> > >> implement
> > >> > the custom executor with
> > >> > HTTP health check. So I am writing this email to check if anyone
> > >> > implemented HTTP health check in custom executor
> > >> > like @swsnider and if you depend on the old protobuf definition of
> > >> > `HealthCheck` heavily.
> > >> > If so, how many month your need for the deprecation cycle of this?
> > >> >
> > >> > Any concerns and questions are appreciated, thanks a lot!
> > >> >
> > >> > --
> > >> > Best Regards,
> > >> > Haosdent Huang
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Haosdent Huang
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
>
