[
https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14619869#comment-14619869
]
Marco Massenzio edited comment on MESOS-2902 at 7/9/15 4:33 AM:
----------------------------------------------------------------
Got it - seems to me that the real issue is that, if the {{--ip}} is not set
and the {{LIBPROCESS_IP}} is not set either (by design or accident) Mesos's
default behavior of using {{127.0.0.1}} (or some other random IP/hostname) is
really the sticky point.
I may be wrong here, but this is what happens in both Master/Slave - looking at
both {{main.cpp}} and the {{Master::initialize()}} and {{Slave::initialize()}}
methods (are there other places?) the behavior is as follows:
- if {{--ip}} is set, set {{LIBPROCESS_IP}} accordingly;
- either way, if {{LIBPROCESS_IP}} is set, try and parse it into a valid IP;
- if it's not set, use {{Address::LOCALHOST_ANY();}} which is essentially
{{0.0.0.0}} and will, ultimately, result in using {{127.0.0.1}} (at least, this
is what happens on OSX, I'm guessing the behavior changes on other
systems/configurations/whatever).
What if we add a {{--ip-explicit}} boolean flag that will result in Mesos
exiting with an error if steps 1. + 2. do not yield a valid IP?
BTW - maybe you don't really need a "wrapper" script; would just a script that
runs at startup (and/or other significant events) which exports LIBPROCESS_IP
be feasible? (sorry, my knowledge of systemd only extends to spelling it right).
was (Author: marco-mesos):
Got it - seems to me that the real issue is that, if the {{--ip}} is not set
and the {{LIBPROCESS_IP}} is not set either (by design or accident) Mesos's
default behavior of using {{127.0.0.1}} (or some other random IP/hostname) is
really the sticky point.
I may be wrong here, but this is what happens in both Master/Slave - looking at
both {{main.cpp}} and the {{Master::initialize()}} and {{Slave::initialize()}}
methods (are there other places?) the behavior is as follows:
- if {{--ip}} is set, set {{LIBPROCESS_IP}} accordingly;
- then, if {{LIBPROCESS_IP}} is set, try and parse it into a valid IP;
- if it's not set, use {{Address::LOCALHOST_ANY();}} which is essentially
{{0.0.0.0}} and will, ultimately, result in using {{127.0.0.1}} (at least, this
is what happens on OSX, I'm guessing the behavior changes on other
systems/configurations/whatever).
What if we add a {{--ip-explicit}} boolean flag that will result in Mesos
exiting with an error if steps 1. + 2. do not yield a valid IP?
BTW - maybe you don't really need a "wrapper" script; would just a script that
runs at startup (and/or other significant events) which exports LIBPROCESS_IP
be feasible? (sorry, my knowledge of systemd only extends to spelling it right).
> Enable Mesos to use arbitrary script / module to figure out IP, HOSTNAME
> ------------------------------------------------------------------------
>
> Key: MESOS-2902
> URL: https://issues.apache.org/jira/browse/MESOS-2902
> Project: Mesos
> Issue Type: Improvement
> Components: master, modules, slave
> Reporter: Cody Maloney
> Assignee: Marco Massenzio
> Priority: Critical
> Labels: mesosphere
>
> Currently Mesos tries to guess the IP, HOSTNAME by doing a reverse DNS
> lookup. This doesn't work on a lot of clouds as we want things like public
> IPs (which aren't the default DNS), there aren't FQDN names (Azure), or the
> correct way to figure it out is to call some cloud-specific endpoint.
> If Mesos / Libprocess could load a mesos-module (Or run a script) which is
> provided per-cloud, we can figure out perfectly the IP / Hostname for the
> given environment. It also means we can ship one identical set of files to
> all hosts in a given provider which doesn't happen to have the DNS scheme +
> hostnames that libprocess/Mesos expects. Currently we have to generate
> host-specific config files which Mesos uses to guess.
> The host-specific files break / fall apart if machines change IP / hostname
> without being reinstalled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
