You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Lukas Loesche (JIRA)" <ji...@apache.org> on 2014/11/14 01:40:34 UTC

[jira] [Comment Edited] (MESOS-2102) Allow configuration of external hostname for web ui

    [ https://issues.apache.org/jira/browse/MESOS-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14211599#comment-14211599 ] 

Lukas Loesche edited comment on MESOS-2102 at 11/14/14 12:40 AM:
-----------------------------------------------------------------

That sounds like a good idea from a technical point of view. Could it be done though without generating a third executable? From a usability point of view I feel like Mesos already has a lot of parts to configure. Adding a third component that has to be configured separately doesn't make that any easier. Just today we had talks about how nice it would be if Mesos was just a single binary that I can execute and it will figure the rest out itself. I.e. why do I have to care about who's master and who's slave. Why can't I just start a single Mesos executable on 10000 nodes and they figure it out themselves (e.g. elect a handful of nodes to possibly become masters and then do leader election amongst those). If I connect to any slave on 5050 it should just redirect me to it's master just like the standby masters currently redirect me to the leading master. Anyways that was just some ideas we had about usability. Don't know how technically feasible they are. But if the web UI was to become a separate executable with it's own configuration that would be the opposite of that. Just my thoughts as a user.


was (Author: lloesche):
That sounds like a good idea from a technical point of view. Could it be done though without generating a third executable? From a usability point of view I feel like Mesos is already has a lot of parts to configure. Adding a third component that has to be configured separately doesn't make that any easier. Just today we had talks about how nice it would be if Mesos was just a single binary that I can execute and it will figure the rest out itself. I.e. why do I have to care about who's master and who's slave. Why can't I just start a single Mesos executable on 10000 nodes and they figure it out themselves (e.g. elect a handful of nodes to possibly become masters and then do leader election amongst those). If I connect to any slave on 5050 it should just redirect me to it's master just like the standby masters currently redirect me to the leading master. Anyways that was just some ideas we had about usability. Don't know how technically feasible they are. But if the web UI was to become a separate executable with it's own configuration that would be the opposite of that. Just my thoughts as a user.

> Allow configuration of external hostname for web ui
> ---------------------------------------------------
>
>                 Key: MESOS-2102
>                 URL: https://issues.apache.org/jira/browse/MESOS-2102
>             Project: Mesos
>          Issue Type: Improvement
>          Components: webui
>    Affects Versions: 0.20.1
>            Reporter: Lukas Loesche
>            Assignee: Joris Van Remoortere
>
> You often have Mesos running in an environment where nodes have internal and external IP addresses.
> It would be advantageous for Mesos and Frameworks to do communication using the internal IPs while users of the web ui connect to the external IPs.
> At the moment if I set --hostname to the internal hostname that hostname is propagated to the web ui and users can't open the slave sandbox. Also the redirect to the active master leads to the wrong hostname then.
> If I set --hostname to the external hostname I have to allow Mesos nodes to communicate with each other using the public IP.
> The way to work around this at the moment is to configure split DNS or /etc/hosts entries.
> It would be nice if I could define something like --webui-hostname or --public-hostname so that nodes communicate via the private interfaces.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)