Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
MIME-Version: 1.0
In-Reply-To: <E2DDCD95-2CAA-456F-9B04-8C67EF86BC29@uber.com>
References: <E2DDCD95-2CAA-456F-9B04-8C67EF86BC29@uber.com>
From: Benjamin Mahler <bmahler@apache.org>
Date: Mon, 7 Mar 2016 18:25:50 -0800
Message-ID: 
 <CAFp_Niv3wwoRDp-XYAdoq9hCGvWp9ovDHSzgOGFatuURn0kAsw@mail.gmail.com>
Subject: Re: State of registrar
To: dev <dev@mesos.apache.org>
Content-Type: multipart/alternative; boundary=089e013a0996f47aa7052d804db0

--089e013a0996f47aa7052d804db0
Content-Type: text/plain; charset=UTF-8

Apologies for the long delay.

I wouldn't call it experimental (that comment is stale), you should feel
free to turn on strictness. Strictness enforces that agents that were
removed by an old master cannot re-join with a new master. This preserves
the steady state behavior: if the master removes an agent, it does not
allow it to return. Ideally, the flag is removed and strictness is the
default, but we didn't feel comfortable removing it until we had state
backup support in the master. Turning off strictness allows for an escape
hatch if state is lost. Now that we are persisting more information than
just the list of agents, this escape hatch doesn't restore the other state
(like maintenance schedules, quota information, etc).

As for why it's not on by default today, we found that many frameworks,
like Aurora and Marathon, are capable of handling a removed agent
re-surfacing in the cluster and so it wasn't critical to turn this on.
Also, we also realized that we need to re-work the partition handling in
Mesos in order to give frameworks the control over how to react to an
unreachable agent.

Does that clarify things?

On Mon, Feb 1, 2016 at 11:04 AM, Zhitao Li <zhitao@uber.com> wrote:

> Hi,
>
> I've been reading related documentation on Mesos website and trying to
> understand the current status of registrar.
>
> I noticed that we still consider "--registrar_strict" as experimental, but
> I can't find the back story of what's needed to finish the project or the
> JIRA so tracking that.
>
> Also, does anyone have recommendations on whether we should turn this flag
> on, and what benefits cluster operator would get?
>
> Thanks.

--089e013a0996f47aa7052d804db0--