Hendrik,
It looks to me that Mesos always pass LIBPROCESS_IP to executor if agent's
LIBPROCESS_IP environment variable is set:
https://github.com/apache/mesos/blob/1.4.x/src/slave/slave.cpp#L8106-L8115
Maybe that's the difference between your vanilla Mesos, and DC/OS Mesos
config?
- Jie
On Fri
Hi,
I had been using Mesos 1.4.1 and now tried out a DC/OS setup (1.9.4) and
noticed that the env variable LIBPROCESS_IP was set. This broke my
scheduler (running as a docker container on Marathon). Things worked
fine again once I unset the variable in my startup script.
I'm now wondering
on. Always passing the LIBRPOCESS_IP into the
> container. I’d argue that, by default, it should not carry the name of the
> var over. It should be avaialble under another name but giving the user the
> option to assign it to LIBPROCESS_IP inside of the container.
> –
> Best regar
option. Always passing the LIBRPOCESS_IP into the
container. I’d argue that, by default, it should not carry the name of the
var over. It should be avaialble under another name but giving the user the
option to assign it to LIBPROCESS_IP inside of the container.
–
Best regards,
Radek Gruchalski
ra
ok like any shell expansion happens long the way (for
good reason, really) so we couldn’t find a way.
Given that you’re using host networking, i’d suggest trying to detect the right
interface to bind to yourself, on the executor side, and set LIBPROCESS_IP= to
the result of that logic be
-
> Best regards,
> Rad
>
>
>
>
> On Tue, Jun 7, 2016 at 3:21 AM +0200, "Eli Jordan" <elias.k.jor...@gmail.com>
> wrote:
>
>> It's important to note that if you run a task with the command executor
>> (I.e. Not using docker) LIBPRO
f you run a task with the command executor (I.e.
Not using docker) LIBPROCESS_IP is defined, along with several other variables
that are not defined in docker.
ThanksEli
On 7 Jun 2016, at 10:05, Radoslaw Gruchalski <ra...@gruchalski.com> wrote:
I think the problem is that it is not known which age
can't have the docket executor set the
LIBPROCESS_IP variable in the same way the command executor does.
Thanks
Eli
On 6 Jun 2016, at 21:44, Radoslaw Gruchalski <ra...@gruchalski.com> wrote:
Out of curiosity. Why are you insisting on using host names?
Say you have 1 master and 2
that in the container and
read the ip.
I would like to avoid having a dependency on the file system of the agents
though. I'm not sure why I can't have the docket executor set the LIBPROCESS_IP
variable in the same way the command executor does.
Thanks
Eli
> On 6 Jun 2016, at 21:44, Radoslaw Gruchalski
rivileged.
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 June 6, 2016 at 1:16:07 PM, Eli Jordan (elias.k.jor...@gmail.com) wrote:
The issue refers to LIBPROCESS_IP not LIBPROCES
The issue refers to LIBPROCESS_IP not LIBPROCESS_HOST. I haven’t been able to
find the LIBPROCESS_HOST variable documented anywhere.
My understanding is that the scheduler uses LIBPROCESS_IP to determine which
network interface to bind to, and also which ip to advertise to the master, so
te
> master(s). You might want to set 'LIBPROCESS_IP' environment variable to use
> a routable IP address.”
>
> I tried setting LIBPROCESS_IP to ‘0.0.0.0’ and LIBPROCESS_ADVERTISE_IP=‘the
> public ip’ and this works. But the host variations don’t seem to work. (i.e.
> set L
ter(s). You might want to set 'LIBPROCESS_IP' environment variable to use a
routable IP address.”
I tried setting LIBPROCESS_IP to ‘0.0.0.0’ and LIBPROCESS_ADVERTISE_IP=‘the
public ip’ and this works. But the host variations don’t seem to work. (i.e.
set LIBPROCESS_IP=0.
.
When running without a docker image LIBPROCESS_IP was defined along with many
other variables.
Sample output when running without docker (note LIBPROCESS_IP) is defined
Registered executor on mesos-slave0
Starting task plain-test.5e5b00cc-2645-11e6-a3dd-080027aa149e
sh -c 'while [ true ]; do env
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
Hello,
Can you try changing your cmd to:
"LIBPROCESS_IP=$HOST ./kafka-mesos.sh scheduler --master=mesos-master:5050
--zk=mesos-master:2181 --api=http://$HOST: <http://mesos-slave0:/>
--storage=zk://kafka-mesos"
and remove constraints and env sections.
On Mon, Apr 4,
pi=http://mesos-slave0:
--storage=zk:/kafka-mesos",
"instances": 1,
"constraints": [["hostname", "LIKE", "mesos-slave0"]],
"env": {
"LIBPROCESS_IP": "192.168.3.16"
}
}
@Chris Bake
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 cor
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 contai
>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 Gruchal
.
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
> environm
21 matches
Mail list logo
