Hi Renat, This is indeed a limitation we are aware of (and which we want to address) You are right about 'communicating back'. The 'libprocess-from' header is set to the scheduler PID (process name + ip) when sending messages from the framework to the master in order for the master to respond (libprocess is one-way HTTP POST). I think the best solution at the moment is to locate the scheduler processes inside the cluster. We can look into the details on the libprocess IP lookup, if you want to be able to bind to a public accessible IP.
A part of the new scheduler API discussions have touched based on this I believe (please jump in if you have specifics to add). One approach which would address this could be to add a notion of an HTTP event-stream which the master can use to communicate back to the scheduler. I am not sure whether we captured this already, but this may be a good time to start a conversation around it. Cheers, Niklas On 27 July 2014 11:47, Renat Bekbolatov <[email protected]> wrote: > Hi guys! > > Mesos scheduler driver picks up machine’s ip address and publishes it to > master to communicate back. If I happened to run a scheduler locally and > connect to my cluster on a private network which has only master exposed, > what is a good workaround to allow information flow from master to > scheduler? > > There is no address setting possible through schedulerDriver API, but even > if I could set the address, it seems like the ports (there are 2 ports > used) are not fixed either. > > Also, I understand that the slave webui components will not work, when > those machines are not exposed, but access to slaves doesn’t block us from > sending tasks to Mesos cluster since the task communication with slaves > goes through the master node. > > I am considering maybe just running that schedulers within the cluster and > expose their services instead, maybe that is a better approach, but please > let me know what you think about both setups. > > Renat
