The reason I need to set LIBPROCESS_IP is because the slaves have 2 network 
interfaces, and the docker container is running in host networking mode. So 
libmesos doesn’t know which IP to advertise. The hostnames of the slaves are 
all resolvable.

I have noticed that if I run a marathon app that doesn’t use docker, e.g. while 
[ true ]; do env; sleep 2; done, that LIBPROCESS_IP is defined in the 
environment. However, when running a docker image this variable is not defined. 

Is there a way to have marathon pass along all environment variables defined by 
mesos?
Thanks
Eli

> On 4 Apr 2016, at 14:12, Eli Jordan <[email protected]> wrote:
> 
> @haosdent I’m not sure how this works internally, but it seems the mess 
> master needs to send requests to the framework for resource offers, and 
> therefore needs to know the external IP (i.e. the host IP)
> 
> @craig w
> Would I need to do this in the cmd portion of the marathon JSON? I currently 
> have the config below
> {
>     "container": ...,
>     "id":"kafka-mesos-scheduler",
>     "cpus": 0.5,
>     "mem": 256,
>     "ports": [9999],
>     "cmd": "./kafka-mesos.sh scheduler --master=mesos-master:5050 
> --zk=mesos-master:2181 --api=http://mesos-slave0:9999 
> --storage=zk:/kafka-mesos",
>     "instances": 1,
>     "constraints": [["hostname", "LIKE", "mesos-slave0"]],
>     "env": {
>         "LIBPROCESS_IP": "192.168.3.16"
>     }
> }
> 
> @Chris Baker Currently we don’t have mess-dns setup but if this works it 
> would seem to be a nice solution. However, I did try setting LIBPROCESS_IP to 
> the slave hostname and it seems to produce a parse error. So I think it needs 
> to be an actual IP address.
> 
> I was hoping there would be a configuration for the slave that would 
> automatically populate this env variable when starting the docker container. 
> So I don’t need to complicate the marathon file, and can reuse it in 
> different clusters.
> 
> 
>> On 4 Apr 2016, at 11:25 am, Chris Baker <[email protected]> wrote:
>> 
>> Alternatively, because the $HOST username is indirect, which would require a 
>> runtime element to "export $LIBPROCESS_IP=$HOST", another alternative is to 
>> fallback on Mesos-DNS, if that's part of the cluster deployment, setting 
>> $LIBPROCESS_IP to the (a priori) Mesos-DNS entry corresponding to the 
>> service.
>> 
>> On Sun, Apr 3, 2016 at 5:06 PM craig w <[email protected]> wrote:
>>> Hi, marathon sets the HOST env var. If it's not the ip address you can use 
>>> getent with the value from HOST to figure it out.
>>> 
>>> >However, in order for the frameworks to receive resource offers I need to 
>>> >set the LIBPROCESS_IP environment variable to the hosts IP address for the 
>>> >docker container running the frameworks. 
>>> 
>>> Hi, @Gmail. Could you provide more details about this?
>>> 
>>>> On Sun, Apr 3, 2016 at 10:40 PM, Rad Gruchalski <[email protected]> 
>>>> wrote:
>>>> Hi Gmail,
>>>> 
>>>> AFAIK not. The only way to do so is setting up the env variable as you do 
>>>> now.
>>>> 
>>>> 
>>>> 
>>>> Kind regards,
>>>> 
>>>> Radek Gruchalski
>>>> 
>>>> [email protected]
>>>> 
>>>> de.linkedin.com/in/radgruchalski/
>>>> 
>>>> Confidentiality:
>>>> This communication is intended for the above-named person and may be 
>>>> confidential and/or legally privileged.
>>>> If it has come to you in error you must take no action based on it, nor 
>>>> must you copy or show it to anyone; please delete/destroy and inform the 
>>>> sender immediately.
>>>>> On Sunday, 3 April 2016 at 16:09, Gmail wrote:
>>>>> 
>>>>> I'm pretty new to mesos and marathon, and I'm running a couple of 
>>>>> frameworks with marathon (Kafka and elastic search). However, in order 
>>>>> for the frameworks to receive resource offers I need to set the 
>>>>> LIBPROCESS_IP environment variable to the hosts IP address for the docker 
>>>>> container running the frameworks. Currently I am working around me this 
>>>>> by using a constraint to hard wire the slave that the framework gets 
>>>>> launched on, so then I can put the slaves ip in the marathon json file.
>>>>> 
>>>>> Obviously this is not ideal. Is there a better way to define the host ip 
>>>>> Inside the docker container?
>>>>> 
>>>>> Sent from my iPad
>>> 
>>> 
>>> 
>>> -- 
>>> Best Regards,
>>> Haosdent Huang
> 

Reply via email to