[
https://issues.apache.org/jira/browse/MESOS-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621226#comment-14621226
]
Cody Maloney commented on MESOS-2902:
-------------------------------------
[~bmahler] Mesos is much more particular and peculiar in it's DNS / Hostname /
IP requirements than a lot of datacenter software. nginx, httpd, etc. don't
actually use the machine's hostname, they purely use whatever a request comes
in as. They also don't publish anywhere saying "This is me come find me" based
on the DNS address of the local machine. They get a request in, they inspect
what IP address / port that request came in on, and in the case of nginx /
apache possibly what the {{Host}} HTTP header is and deal with it from there.
In the case of Mesos for the Masters for instance if a master and framework
disagree on the master IP, you just end up with lost packets with no logging
currently. The HTTP API should help in this area, but we need to ship Mesos
today / can't wait for that to come.
We only use cloud-init in some environments. And it only has coreos public /
private IPv4. There are environments we install using the myriad of other host
install / setup tools (chef, salt, fleet, ...). There are a lot of ways we ship
this stuff to clients.
Adding one simple flag doesn't considerably add to the Mesos maintenance
burden, and solves our use case at the moment. If adding a flag is unpalatable,
it could be added as a mesos 'hook' module which does exactly the same thing,
just makes the IP lookup pluggable. That would make it so someone could write a
mesos module which does NetworkManager if they wished (Although there will
still be a problem of Mesos slave can't handle when it's IP address changes)
This isn't teaching mesos configuration management at all. It is trying to get
it out of the policy of trying to self-configure itself badly for a lot of our
customer environments, leading to lots of headaches for various customers we
are trying to ship Mesos as a component of DCOS to.
The maintenance burden for this is no more than the `--ip` flag that Mesos has
currently which is the exact same as setting LIBPROCESS_IP. It does not
significantly effect organizations which do not need the flag / wish to use it
I believe, and if they don't give it, it will not change the behavior of their
setups.
> 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)
