Folks,
There have been a bunch of online [1, 2] and offline discussions about our
deprecation and versioning policy. I found that people—including
myself—read the versioning doc [3] differently; moreover some aspects are
not captured there. I would like to start a discussion around this topic by
Stephan,
I think the only time the framework needs to set LIBPROCESS_ADVERTISE_IP is
when DNAT is necessary for the container (e.g., bridge). In that
case, LIBPROCESS_ADVERTISE_IP should always be agent ip and
the relevant host port allocated for the container. For other cases,
framework should
I'd like to notify framework to kill its tasks and then terminate the
mesos-agent. To the Maintenance feature, can not remember whether the slave
info will be clearup if that slave will not re-register back.
On Wed, Oct 12, 2016 at 10:13 PM Alex Rukletsov wrote:
> To make
To make sure: you are aware of SIGUSR1?
On Tue, Oct 11, 2016 at 5:37 PM, tommy xiao wrote:
> Hi Ma,
>
> could you please input more background, why Maintenance feature is not
> best option for your request?
>
> 2016-10-11 14:47 GMT+08:00 haosdent :
>
> >
Folks,
we have 23 unresolved tickets targeted for Mesos 1.1.0 release, including 7
blockers and 3 epics (MESOS-5344, MESOS-3421, MESOS-2449), which turns 23
into 55. Obviously, we can’t make a cut today.
Shepherds please either commit your blockers by Thu EOD PST or declare them
as non-blockers.
>
> Also, I think libprocess should always bind to 0.0.0.0, rather than doing a
> hostname lookup and bind to the IP found for the hostname.
> LIBPROCESS_ADVERTISE_IP can be used to overwrite the ip address it wants to
> advertise to peers. If that's not specified, it'll try to do a hostname
>
>Framework should be the one that sets
>LIBPROCESS_ADVERTISE_IP and LIBPROCESS_ADVERTISE_PORT appropriately if it
>tries to launch another Mesos framework so that Master can reach the new
>framework.
As a framework/executor author this is not possible in all scenarios: There is
no way to