Re: Why task environment variables are set for executor/containerizer?

[Tomek Janiszewski]

Created issue: https://issues.apache.org/jira/browse/MESOS-6945

śr., 18 sty 2017 o 17:54 użytkownik Jie Yu  napisał:

> Can you create a ticket for that? I personally want to fix that for
> command executor.
>
> - Jie
>
> On Wed, Jan 18, 2017 at 5:52 PM, Jie Yu  wrote:
>
> Daniel,
>
> Yes, this is a tech debt in the old command executor. The new default
> executor does not have this issue.
>
> - Jie
>
> On Wed, Jan 18, 2017 at 5:49 PM, Daniel Krawczyk 
> wrote:
>
> Hi,
>
> When I set an environment variable for my task it is as well applied both
> to mesos-containerizer and mesos-executor.
> This may lead to problems, for example when loading dynamic libraries with
> LD_PRELOAD.
>
> Is setting task variables to executor/containerizer a bug?
>
> Cheers,
> Daniel
>
>
>
>

Re: Why task environment variables are set for executor/containerizer?

[Jie Yu]

Daniel,

Yes, this is a tech debt in the old command executor. The new default
executor does not have this issue.

- Jie

On Wed, Jan 18, 2017 at 5:49 PM, Daniel Krawczyk  wrote:

> Hi,
>
> When I set an environment variable for my task it is as well applied both
> to mesos-containerizer and mesos-executor.
> This may lead to problems, for example when loading dynamic libraries with
> LD_PRELOAD.
>
> Is setting task variables to executor/containerizer a bug?
>
> Cheers,
> Daniel
>
>

Re: Why task environment variables are set for executor/containerizer?

[Jie Yu]

Can you create a ticket for that? I personally want to fix that for command
executor.

- Jie

On Wed, Jan 18, 2017 at 5:52 PM, Jie Yu  wrote:

> Daniel,
>
> Yes, this is a tech debt in the old command executor. The new default
> executor does not have this issue.
>
> - Jie
>
> On Wed, Jan 18, 2017 at 5:49 PM, Daniel Krawczyk 
> wrote:
>
>> Hi,
>>
>> When I set an environment variable for my task it is as well applied both
>> to mesos-containerizer and mesos-executor.
>> This may lead to problems, for example when loading dynamic libraries
>> with LD_PRELOAD.
>>
>> Is setting task variables to executor/containerizer a bug?
>>
>> Cheers,
>> Daniel
>>
>>
>

Why task environment variables are set for executor/containerizer?

[Daniel Krawczyk]

Hi,

When I set an environment variable for my task it is as well applied both
to mesos-containerizer and mesos-executor.
This may lead to problems, for example when loading dynamic libraries with
LD_PRELOAD.

Is setting task variables to executor/containerizer a bug?

Cheers,
Daniel

ApacheCon CFP closing soon (11 February)

[Rich Bowen]

Hello, fellow Apache enthusiast. Thanks for your participation, and
interest in, the projects of the Apache Software Foundation.

I wanted to remind you that the Call For Papers (CFP) for ApacheCon
North America, and Apache: Big Data North America, closes in less than a
month. If you've been putting it off because there was lots of time
left, it's time to dig for that inspiration and get those talk proposals in.

It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.

We're looking for talks directly, and indirectly, related to projects at
the Apache Software Foundation. These can be anything from in-depth
technical discussions of the projects you work with, to talks about
community, documentation, legal issues, marketing, and so on. We're also
very interested in talks about projects and services built on top of
Apache projects, and case studies of how you use Apache projects to
solve real-world problems.

We are particularly interested in presentations from Apache projects
either in the Incubator, or recently graduated. ApacheCon is where
people come to find out what technology they'll be using this time next
year.

Important URLs are:

To submit a talk for Apache: Big Data -
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
To submit a talk for ApacheCon -
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp

To register for Apache: Big Data -
http://events.linuxfoundation.org/events/apache-big-data-north-america/attend/register-
To register for ApacheCon -
http://events.linuxfoundation.org/events/apachecon-north-america/attend/register-

Early Bird registration rates end March 12th, but if you're a committer
on an Apache project, you get the low committer rate, which is less than
half of the early bird rate!

For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network. Or
contact me - rbo...@apache.org - with any questions or concerns.

Thanks!

Rich Bowen, VP Conferences, Apache Software Foundation

-- 
(You've received this email because you're on a dev@ or users@ mailing
list of an Apache Software Foundation project. For subscription and
unsubscription information, consult the headers of this email message,
as this varies from one list to another.)

Re: customized IP for health check

[CmingXu]

Got it，
Let  user specify health checks with COMMAND(not for port but pid file
maybe) seems the only option I have.

Thanks a alot for the response and the hard work for Mesos.

On Wed, Jan 18, 2017 at 7:37 PM, Jie Yu  wrote:

> Had a discussion with Vinod and AlexR on this.
>
> I DO think it's common that frameworks do not know about the IP of the
> container before launching it. For instance, any networking solution that
> has a dynamic IPAM (e.g., calico, dc/os overlay, weave, etc.).
>
> For those cases, probably doesn't make sense to ask the frameworks (or
> users) to specify the health check ip addresses for their containers.
>
> One solution we discussed was to use the container ip by default, but
> optionally allow people to specify `LOCALHOST` if they want to (this is
> what k8s does for probe. what's different is that k8s performs health check
> from kublet which runs outside the container network, while Mesos perform
> health checks from the executor which is in the same network as the
> container).
>
> However, the downside for this approach is that if a container joins
> multiple networks, what should be the address that Mesos uses to do health
> check by default?
>
> Therefore, I personally prefer a more consistent semantics (i.e., always
> using localhost). Although we can always add a backdoor for allowing people
> to specify a custom address for health check, but this should be avoided if
> possible.
>
> - Jie
>
> On Wed, Jan 18, 2017 at 10:44 AM, CmingXu  wrote:
>
>> The framework user have to make sure the IPs assigned unique and
>> accessible within the VLAN.
>>
>> In some cases, framework user want their DB, Cache or Proxy type of apps
>> handled by my framework & mesos, they might also want the app treated as
>> they are deployed  as the old way, which have a unique IP for each
>> container.
>>
>> This kind of app is not the only type that my framework support, with
>> BRIDGE driver supported too.
>>
>> On Wed, Jan 18, 2017 at 5:30 PM, Jie Yu  wrote:
>>
>>> It's also possible that the IP is not known by the task/framework
>>> upfront (in fact, this is quite common depending on the underlying network
>>> driver), what does your general framework do in this case?
>>>
>>> - Jie
>>>
>>> On Wed, Jan 18, 2017 at 10:26 AM, CmingXu  wrote:
>>>
 I am not sure what kind of apps are going to be running on Mesos, what
 I am doing is a general purpose framework kind of like Marathon.

 On Wed, Jan 18, 2017 at 5:24 PM, Jie Yu  wrote:

> and we don't know if the task listening on all interfaces or not
>
>
> OK, i think that's the reason. Although, i am wondering: the task is
> already listening on an external IP, why not just listen on 0.0.0.0. Any
> specific reason this is a concern? Or just because there is no way to
> configure the listening address of the task?
>
> - Jie
>
> On Wed, Jan 18, 2017 at 10:17 AM, CmingXu  wrote:
>
>> To Alex:
>> Yes, we know the IP upfront, framework user need reserve unique IP
>> for each task, and we don't know if the task listening on all interfaces 
>> or
>> not, so let the health check on the IP is the best option.
>>
>>
>>
>> To Jie Yu:
>>
>> by DEFAULT_DOMAIN I mean
>>
>> *static const string DEFAULT_DOMAIN = "127.0.0.1"*
>>
>> in source code src/health-check/health_checker.cpp
>>
>> On Wed, Jan 18, 2017 at 4:58 PM, Jie Yu  wrote:
>>
>>> So you want to use the IP addressed assigned by your macvlan driver
>>> to do health check? If that's the case, I still don't understand why
>>> entering the network namespace of the container and use localhost for
>>> health check does not work (which is what Mesos is doing).
>>>
>>> I walked through the Mesos source code and obviously the TCP & HTTP
 doesn't meet my requirements as DEFAULT_DOMAIN is hard coded
>>>
>>>
>>> What do you mean by DEFAULT_DOMAIN?
>>>
>>> - Jie
>>>
>>> On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:
>>>
 the network I am currently used is USER, and each task was assigned
 with a unique vLAN IP with the underlaying docker driver is
 Macvlan. I
 want my framework user have the ability to define there own
 HealthChecks with the IP assigned to a specific task.

 I walked through the Mesos source code and obviously the TCP & HTTP
 doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now
 the
 only option to be might be health check with COMMAND, but if TCP
 does
 support passing IP would be great help.

 Thanks

 On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu 
 wrote:
 > Hi, 

Re: customized IP for health check

[Jie Yu]

Had a discussion with Vinod and AlexR on this.

I DO think it's common that frameworks do not know about the IP of the
container before launching it. For instance, any networking solution that
has a dynamic IPAM (e.g., calico, dc/os overlay, weave, etc.).

For those cases, probably doesn't make sense to ask the frameworks (or
users) to specify the health check ip addresses for their containers.

One solution we discussed was to use the container ip by default, but
optionally allow people to specify `LOCALHOST` if they want to (this is
what k8s does for probe. what's different is that k8s performs health check
from kublet which runs outside the container network, while Mesos perform
health checks from the executor which is in the same network as the
container).

However, the downside for this approach is that if a container joins
multiple networks, what should be the address that Mesos uses to do health
check by default?

Therefore, I personally prefer a more consistent semantics (i.e., always
using localhost). Although we can always add a backdoor for allowing people
to specify a custom address for health check, but this should be avoided if
possible.

- Jie

On Wed, Jan 18, 2017 at 10:44 AM, CmingXu  wrote:

> The framework user have to make sure the IPs assigned unique and
> accessible within the VLAN.
>
> In some cases, framework user want their DB, Cache or Proxy type of apps
> handled by my framework & mesos, they might also want the app treated as
> they are deployed  as the old way, which have a unique IP for each
> container.
>
> This kind of app is not the only type that my framework support, with
> BRIDGE driver supported too.
>
> On Wed, Jan 18, 2017 at 5:30 PM, Jie Yu  wrote:
>
>> It's also possible that the IP is not known by the task/framework upfront
>> (in fact, this is quite common depending on the underlying network driver),
>> what does your general framework do in this case?
>>
>> - Jie
>>
>> On Wed, Jan 18, 2017 at 10:26 AM, CmingXu  wrote:
>>
>>> I am not sure what kind of apps are going to be running on Mesos, what I
>>> am doing is a general purpose framework kind of like Marathon.
>>>
>>> On Wed, Jan 18, 2017 at 5:24 PM, Jie Yu  wrote:
>>>
 and we don't know if the task listening on all interfaces or not


 OK, i think that's the reason. Although, i am wondering: the task is
 already listening on an external IP, why not just listen on 0.0.0.0. Any
 specific reason this is a concern? Or just because there is no way to
 configure the listening address of the task?

 - Jie

 On Wed, Jan 18, 2017 at 10:17 AM, CmingXu  wrote:

> To Alex:
> Yes, we know the IP upfront, framework user need reserve unique IP for
> each task, and we don't know if the task listening on all interfaces or
> not, so let the health check on the IP is the best option.
>
>
>
> To Jie Yu:
>
> by DEFAULT_DOMAIN I mean
>
> *static const string DEFAULT_DOMAIN = "127.0.0.1"*
>
> in source code src/health-check/health_checker.cpp
>
> On Wed, Jan 18, 2017 at 4:58 PM, Jie Yu  wrote:
>
>> So you want to use the IP addressed assigned by your macvlan driver
>> to do health check? If that's the case, I still don't understand why
>> entering the network namespace of the container and use localhost for
>> health check does not work (which is what Mesos is doing).
>>
>> I walked through the Mesos source code and obviously the TCP & HTTP
>>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded
>>
>>
>> What do you mean by DEFAULT_DOMAIN?
>>
>> - Jie
>>
>> On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:
>>
>>> the network I am currently used is USER, and each task was assigned
>>> with a unique vLAN IP with the underlaying docker driver is Macvlan.
>>> I
>>> want my framework user have the ability to define there own
>>> HealthChecks with the IP assigned to a specific task.
>>>
>>> I walked through the Mesos source code and obviously the TCP & HTTP
>>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
>>> only option to be might be health check with COMMAND, but if TCP does
>>> support passing IP would be great help.
>>>
>>> Thanks
>>>
>>> On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
>>> > Hi, can you elaborate a bit more on why you need to use an
>>> customized IP,
>>> > rather than using localhost for health check?
>>> >
>>> > - Jie
>>> >
>>> > On Wed, Jan 18, 2017 at 9:19 AM, CmingXu 
>>> wrote:
>>> >>
>>> >> Is there any plan we support customized IP when define a health
>>> check?
>>> >> If true, what's the ETA?
>>> >>
>>> >> 

Re: Question on dynamic reservations

[Povilas Versockas]

Thanks for information and ideas! I think labeled static reservation would
help if framework could modify labels during runtime.

Personally I think statically reserved resources should be offered only to
frameworks but look like free (role:*) resources. Then framework developers
could use labeled dynamic reservations and there won’t be any code
differences handling static reservations and dynamic reservations. And this
would make current frameworks like Cassandra or dcos-commons library
support static reservation.

Given the current situation it looks like quota may be a solution for me.
The current idea is to create a custom resource on my mesos-agents and set
a quota.

Example:

Set mesos-agent with flag:

--resources
cpus(*):8;mem(*):4096;disk(*):4096;ports(*):[31000-32000];mysql(*):1


And then using operators API set quota:

{

   "role": “role”,

   "guarantee": [

 {

   "name": "cpus",

   "type": "SCALAR",

   "scalar": { "value": 8 }

 },

 {

   "name": "mem",

   "type": "SCALAR",

   "scalar": { "value": 4096 }

 },

…

 {

   "name": “mysql”,

   "type": "SCALAR",

   "scalar": { "value": 1 }

 }

   ]

 }


This should make mesos-master save agent’s resources for my role and let me
use dynamic reservations.



On Wed, Jan 18, 2017 at 2:29 AM, Greg Mann  wrote:

> Thanks Gabriel, that makes sense. It sounds like labels on static
> reservations might be the most expedient path toward a solution to this
> problem, but that is not without its complications, as suggested in the
> related ticket which Neil filed a while back: https://issues.apache.
> org/jira/browse/MESOS-4476
>
> Povilas, also see this related ticket that Gabriel pointed me to:
> https://issues.apache.org/jira/browse/MESOS-6939
>
> It sounds like this is a real issue for stateful framework developers, so
> hopefully we will find some time soon to implement a solution. In the
> meantime, Povilas, I'm afraid to say I don't know exactly what solution to
> recommend. If anybody else in the community has some ideas, it would be
> great to hear them :)
>
> Cheers,
> Greg
>
>
> On Tue, Jan 17, 2017 at 2:52 PM, Gabriel Hartmann 
> wrote:
>
>> @Greg: The reason people use static reservation is to enforce that
>> particular resources (usually disks) can only be consumed by a particular
>> framework.  They also don't know when the stateful service is going to be
>> installed necessarily so they don't want to race with other frameworks to
>> consume those special resources.  So static reservation is desirable.
>> However, all stateful services also need more information about reserved
>> resources than is natively provided by Mesos in the static reservation case
>> (i.e. the labels he describes).  `dcos-commons` does the same thing.
>> Various work arounds exist, but none are able to provide resource
>> allocation enforcement because only roles do that.  An alternate resource
>> allocation enforcement mechanism is needed.  Usually this is the part where
>> people start talking about quota.
>>
>> Neither option 1 nor option 2 provided a race proof way to get fully
>> labeled reserved resources.  It's been proposed in the past that it be
>> allowed to add labels to statically reserved resources.  That's kind of
>> fine except now you have these things that can't really be UNRESERVEd but
>> look exactly like dynamic resources which can...
>>
>> Quota w/ chunks as a step in the deployment of stateful services is very
>> desirable in an adversarial environment.  However if your'e in a
>> cooperative environment (i.e. you're not in an adversarial relationship
>> with other frameworks) if you had resources (particularly disk resources)
>> with attributes on them you could have frameworks voluntarily choose not to
>> consume resources not meant for them.
>>
>> e.g. Disk resource has attribute `CASSANDRA`.  Ok, since I'm a Kafka
>> framework I won't go use that disk.
>>
>> On Tue, Jan 17, 2017 at 11:24 AM Greg Mann  wrote:
>>
>>> Hi Povilas,
>>> Another approach you could try is to use dynamic reservations only. You
>>> could either:
>>>
>>>1. Alter your stateful framework to dynamically reserve the
>>>resources that it needs, or
>>>2. Add a script to your cluster tooling that would make use of the
>>>operator endpoint for dynamic reservations [1]
>>> to
>>>dynamically reserve the stateful framework's resources when your cluster 
>>> is
>>>initially provisioned. This would have a similar effect to static
>>>reservations, but would allow you to set labels
>>>
>>> Approach #1 makes sense to me; is there a reason that it's not feasible
>>> for your stateful framework to dynamically reserve its own resources? This
>>> is the typical workflow that I would recommend. I'm not too familiar with
>>> Aurora, so perhaps it's adding some complexity 

Re: customized IP for health check

[CmingXu]

The framework user have to make sure the IPs assigned unique and accessible
within the VLAN.

In some cases, framework user want their DB, Cache or Proxy type of apps
handled by my framework & mesos, they might also want the app treated as
they are deployed  as the old way, which have a unique IP for each
container.

This kind of app is not the only type that my framework support, with
BRIDGE driver supported too.

On Wed, Jan 18, 2017 at 5:30 PM, Jie Yu  wrote:

> It's also possible that the IP is not known by the task/framework upfront
> (in fact, this is quite common depending on the underlying network driver),
> what does your general framework do in this case?
>
> - Jie
>
> On Wed, Jan 18, 2017 at 10:26 AM, CmingXu  wrote:
>
>> I am not sure what kind of apps are going to be running on Mesos, what I
>> am doing is a general purpose framework kind of like Marathon.
>>
>> On Wed, Jan 18, 2017 at 5:24 PM, Jie Yu  wrote:
>>
>>> and we don't know if the task listening on all interfaces or not
>>>
>>>
>>> OK, i think that's the reason. Although, i am wondering: the task is
>>> already listening on an external IP, why not just listen on 0.0.0.0. Any
>>> specific reason this is a concern? Or just because there is no way to
>>> configure the listening address of the task?
>>>
>>> - Jie
>>>
>>> On Wed, Jan 18, 2017 at 10:17 AM, CmingXu  wrote:
>>>
 To Alex:
 Yes, we know the IP upfront, framework user need reserve unique IP for
 each task, and we don't know if the task listening on all interfaces or
 not, so let the health check on the IP is the best option.



 To Jie Yu:

 by DEFAULT_DOMAIN I mean

 *static const string DEFAULT_DOMAIN = "127.0.0.1"*

 in source code src/health-check/health_checker.cpp

 On Wed, Jan 18, 2017 at 4:58 PM, Jie Yu  wrote:

> So you want to use the IP addressed assigned by your macvlan driver to
> do health check? If that's the case, I still don't understand why entering
> the network namespace of the container and use localhost for health check
> does not work (which is what Mesos is doing).
>
> I walked through the Mesos source code and obviously the TCP & HTTP
>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded
>
>
> What do you mean by DEFAULT_DOMAIN?
>
> - Jie
>
> On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:
>
>> the network I am currently used is USER, and each task was assigned
>> with a unique vLAN IP with the underlaying docker driver is Macvlan. I
>> want my framework user have the ability to define there own
>> HealthChecks with the IP assigned to a specific task.
>>
>> I walked through the Mesos source code and obviously the TCP & HTTP
>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
>> only option to be might be health check with COMMAND, but if TCP does
>> support passing IP would be great help.
>>
>> Thanks
>>
>> On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
>> > Hi, can you elaborate a bit more on why you need to use an
>> customized IP,
>> > rather than using localhost for health check?
>> >
>> > - Jie
>> >
>> > On Wed, Jan 18, 2017 at 9:19 AM, CmingXu 
>> wrote:
>> >>
>> >> Is there any plan we support customized IP when define a health
>> check?
>> >> If true, what's the ETA?
>> >>
>> >> thanks
>> >
>> >
>>
>
>

>>>
>>
>

Re: customized IP for health check

[CmingXu]

I am not sure what kind of apps are going to be running on Mesos, what I am
doing is a general purpose framework kind of like Marathon.

On Wed, Jan 18, 2017 at 5:24 PM, Jie Yu  wrote:

> and we don't know if the task listening on all interfaces or not
>
>
> OK, i think that's the reason. Although, i am wondering: the task is
> already listening on an external IP, why not just listen on 0.0.0.0. Any
> specific reason this is a concern? Or just because there is no way to
> configure the listening address of the task?
>
> - Jie
>
> On Wed, Jan 18, 2017 at 10:17 AM, CmingXu  wrote:
>
>> To Alex:
>> Yes, we know the IP upfront, framework user need reserve unique IP for
>> each task, and we don't know if the task listening on all interfaces or
>> not, so let the health check on the IP is the best option.
>>
>>
>>
>> To Jie Yu:
>>
>> by DEFAULT_DOMAIN I mean
>>
>> *static const string DEFAULT_DOMAIN = "127.0.0.1"*
>>
>> in source code src/health-check/health_checker.cpp
>>
>> On Wed, Jan 18, 2017 at 4:58 PM, Jie Yu  wrote:
>>
>>> So you want to use the IP addressed assigned by your macvlan driver to
>>> do health check? If that's the case, I still don't understand why entering
>>> the network namespace of the container and use localhost for health check
>>> does not work (which is what Mesos is doing).
>>>
>>> I walked through the Mesos source code and obviously the TCP & HTTP
 doesn't meet my requirements as DEFAULT_DOMAIN is hard coded
>>>
>>>
>>> What do you mean by DEFAULT_DOMAIN?
>>>
>>> - Jie
>>>
>>> On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:
>>>
 the network I am currently used is USER, and each task was assigned
 with a unique vLAN IP with the underlaying docker driver is Macvlan. I
 want my framework user have the ability to define there own
 HealthChecks with the IP assigned to a specific task.

 I walked through the Mesos source code and obviously the TCP & HTTP
 doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
 only option to be might be health check with COMMAND, but if TCP does
 support passing IP would be great help.

 Thanks

 On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
 > Hi, can you elaborate a bit more on why you need to use an customized
 IP,
 > rather than using localhost for health check?
 >
 > - Jie
 >
 > On Wed, Jan 18, 2017 at 9:19 AM, CmingXu  wrote:
 >>
 >> Is there any plan we support customized IP when define a health
 check?
 >> If true, what's the ETA?
 >>
 >> thanks
 >
 >

>>>
>>>
>>
>

Re: customized IP for health check

[Jie Yu]

>
> and we don't know if the task listening on all interfaces or not


OK, i think that's the reason. Although, i am wondering: the task is
already listening on an external IP, why not just listen on 0.0.0.0. Any
specific reason this is a concern? Or just because there is no way to
configure the listening address of the task?

- Jie

On Wed, Jan 18, 2017 at 10:17 AM, CmingXu  wrote:

> To Alex:
> Yes, we know the IP upfront, framework user need reserve unique IP for
> each task, and we don't know if the task listening on all interfaces or
> not, so let the health check on the IP is the best option.
>
>
>
> To Jie Yu:
>
> by DEFAULT_DOMAIN I mean
>
> *static const string DEFAULT_DOMAIN = "127.0.0.1"*
>
> in source code src/health-check/health_checker.cpp
>
> On Wed, Jan 18, 2017 at 4:58 PM, Jie Yu  wrote:
>
>> So you want to use the IP addressed assigned by your macvlan driver to do
>> health check? If that's the case, I still don't understand why entering the
>> network namespace of the container and use localhost for health check does
>> not work (which is what Mesos is doing).
>>
>> I walked through the Mesos source code and obviously the TCP & HTTP
>>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded
>>
>>
>> What do you mean by DEFAULT_DOMAIN?
>>
>> - Jie
>>
>> On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:
>>
>>> the network I am currently used is USER, and each task was assigned
>>> with a unique vLAN IP with the underlaying docker driver is Macvlan. I
>>> want my framework user have the ability to define there own
>>> HealthChecks with the IP assigned to a specific task.
>>>
>>> I walked through the Mesos source code and obviously the TCP & HTTP
>>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
>>> only option to be might be health check with COMMAND, but if TCP does
>>> support passing IP would be great help.
>>>
>>> Thanks
>>>
>>> On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
>>> > Hi, can you elaborate a bit more on why you need to use an customized
>>> IP,
>>> > rather than using localhost for health check?
>>> >
>>> > - Jie
>>> >
>>> > On Wed, Jan 18, 2017 at 9:19 AM, CmingXu  wrote:
>>> >>
>>> >> Is there any plan we support customized IP when define a health check?
>>> >> If true, what's the ETA?
>>> >>
>>> >> thanks
>>> >
>>> >
>>>
>>
>>
>

Re: customized IP for health check

[CmingXu]

To Alex:
Yes, we know the IP upfront, framework user need reserve unique IP for each
task, and we don't know if the task listening on all interfaces or not, so
let the health check on the IP is the best option.



To Jie Yu:

by DEFAULT_DOMAIN I mean

*static const string DEFAULT_DOMAIN = "127.0.0.1"*

in source code src/health-check/health_checker.cpp

On Wed, Jan 18, 2017 at 4:58 PM, Jie Yu  wrote:

> So you want to use the IP addressed assigned by your macvlan driver to do
> health check? If that's the case, I still don't understand why entering the
> network namespace of the container and use localhost for health check does
> not work (which is what Mesos is doing).
>
> I walked through the Mesos source code and obviously the TCP & HTTP
>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded
>
>
> What do you mean by DEFAULT_DOMAIN?
>
> - Jie
>
> On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:
>
>> the network I am currently used is USER, and each task was assigned
>> with a unique vLAN IP with the underlaying docker driver is Macvlan. I
>> want my framework user have the ability to define there own
>> HealthChecks with the IP assigned to a specific task.
>>
>> I walked through the Mesos source code and obviously the TCP & HTTP
>> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
>> only option to be might be health check with COMMAND, but if TCP does
>> support passing IP would be great help.
>>
>> Thanks
>>
>> On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
>> > Hi, can you elaborate a bit more on why you need to use an customized
>> IP,
>> > rather than using localhost for health check?
>> >
>> > - Jie
>> >
>> > On Wed, Jan 18, 2017 at 9:19 AM, CmingXu  wrote:
>> >>
>> >> Is there any plan we support customized IP when define a health check?
>> >> If true, what's the ETA?
>> >>
>> >> thanks
>> >
>> >
>>
>
>

Re: customized IP for health check

[Jie Yu]

So you want to use the IP addressed assigned by your macvlan driver to do
health check? If that's the case, I still don't understand why entering the
network namespace of the container and use localhost for health check does
not work (which is what Mesos is doing).

I walked through the Mesos source code and obviously the TCP & HTTP
> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded


What do you mean by DEFAULT_DOMAIN?

- Jie

On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:

> the network I am currently used is USER, and each task was assigned
> with a unique vLAN IP with the underlaying docker driver is Macvlan. I
> want my framework user have the ability to define there own
> HealthChecks with the IP assigned to a specific task.
>
> I walked through the Mesos source code and obviously the TCP & HTTP
> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
> only option to be might be health check with COMMAND, but if TCP does
> support passing IP would be great help.
>
> Thanks
>
> On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
> > Hi, can you elaborate a bit more on why you need to use an customized IP,
> > rather than using localhost for health check?
> >
> > - Jie
> >
> > On Wed, Jan 18, 2017 at 9:19 AM, CmingXu  wrote:
> >>
> >> Is there any plan we support customized IP when define a health check?
> >> If true, what's the ETA?
> >>
> >> thanks
> >
> >
>

Re: customized IP for health check

[Alex Rukletsov]

I'm not sure that exposing a domain will help: do you know the IP of your
task upfront, i.e., at the moment when you construct TaskInfo? Isn't your
task listening on all interfaces?

On Wed, Jan 18, 2017 at 9:54 AM, CmingXu  wrote:

> the network I am currently used is USER, and each task was assigned
> with a unique vLAN IP with the underlaying docker driver is Macvlan. I
> want my framework user have the ability to define there own
> HealthChecks with the IP assigned to a specific task.
>
> I walked through the Mesos source code and obviously the TCP & HTTP
> doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
> only option to be might be health check with COMMAND, but if TCP does
> support passing IP would be great help.
>
> Thanks
>
> On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
> > Hi, can you elaborate a bit more on why you need to use an customized IP,
> > rather than using localhost for health check?
> >
> > - Jie
> >
> > On Wed, Jan 18, 2017 at 9:19 AM, CmingXu  wrote:
> >>
> >> Is there any plan we support customized IP when define a health check?
> >> If true, what's the ETA?
> >>
> >> thanks
> >
> >
>

Re: customized IP for health check

[CmingXu]

the network I am currently used is USER, and each task was assigned
with a unique vLAN IP with the underlaying docker driver is Macvlan. I
want my framework user have the ability to define there own
HealthChecks with the IP assigned to a specific task.

I walked through the Mesos source code and obviously the TCP & HTTP
doesn't meet my requirements as DEFAULT_DOMAIN is hard coded, now the
only option to be might be health check with COMMAND, but if TCP does
support passing IP would be great help.

Thanks

On Wed, Jan 18, 2017 at 4:40 PM, Jie Yu  wrote:
> Hi, can you elaborate a bit more on why you need to use an customized IP,
> rather than using localhost for health check?
>
> - Jie
>
> On Wed, Jan 18, 2017 at 9:19 AM, CmingXu  wrote:
>>
>> Is there any plan we support customized IP when define a health check?
>> If true, what's the ETA?
>>
>> thanks
>
>

Re: customized IP for health check

[Jie Yu]

Hi, can you elaborate a bit more on why you need to use an customized IP,
rather than using localhost for health check?

- Jie

On Wed, Jan 18, 2017 at 9:19 AM, CmingXu  wrote:

> Is there any plan we support customized IP when define a health check?
> If true, what's the ETA?
>
> thanks
>

customized IP for health check

[CmingXu]

Is there any plan we support customized IP when define a health check?
If true, what's the ETA?

thanks