Open SEJeff opened 8 years ago
Hi @SEJeff, thank you for your feedback.
Probably, this is out of the scope of Scheduler. Mesos should be correctly installed on all slaves. On the environments, I've tried there is a symlink like /usr/lib/libmesos.so -> libmesos-0.25.0.so
.
So creating a symlink, seems to be a correct fix and not a workaround.
Regarding your solution. MESOS_NATIVE_LIBRARY
should be defined on each slave, running the executor. If it is defined only on host, running the Scheduler, it will have no effect. And spreading the value of MESOS_NATIVE_LIBRARY
from the Scheduler to Executors, also seems to be wrong approach, because different slaves could have different library placement (for instance, running different mesos versions, archs, OSes etc).
Please comment on this, If I understood your situation incorrectly or made a mistake. In case of silence will close the ticket in 10 days.
@dmitrypekar I had it defined on each slave in a file under /etc/mesos. However, there is no way for me to have the tasks reference this, so there was no way for me to define it other than a symlink.
Perhaps this feature could be changed for a way to specify env vars that each broker gets? Would get be reasonable?
Before starting the scheduler, I'm exporting
$MESOS_NATIVE_LIBRARY
as the path to the mesos library on the framework machine and all mesos agent machines.This is not honored and when it tries to start a broker, it errors out with:
It is looking for libmesos.so under /usr/lib64, but the mesos package I'm using doesn't install libmesos.so, only libmesos.so.$VERSION ie: libmesos.so.22.
The framework should honor the
MESOS_NATIVE_LIBRARY
env variable if available. My workaround was to symlink/usr/lib64/libmesos.so.22 --> /usr/lib64/libmesos.so
, but it seems like this is a reasonable thing to support.