[
https://issues.apache.org/jira/browse/MESOS-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242958#comment-16242958
]
James Peach commented on MESOS-8169:
------------------------------------
{noformat}
commit 76fcf0e6d2160bec29f6966c400c57ffb8e64bda (HEAD -> master, origin/master,
origin/HEAD)
Author: James DeFelice <[email protected]>
Date: Mon Nov 6 16:53:41 2017 -0800
Fixed incorrect validation that forced ExecutorID uniqueness.
In the ReregisterSlaveMessage message validation, we were
requiring the ExecutorID to be unique across a whole agent.
In fact, only the {FrameworkID, ExecutorID} tuple must be
unique.
This closes #248
{noformat}
> master validation incorrectly rejects slaves, buggy executorID checking
> -----------------------------------------------------------------------
>
> Key: MESOS-8169
> URL: https://issues.apache.org/jira/browse/MESOS-8169
> Project: Mesos
> Issue Type: Bug
> Affects Versions: 1.4.0
> Reporter: James DeFelice
> Assignee: James DeFelice
> Labels: mesosphere
>
> proposed fix: https://github.com/apache/mesos/pull/248
> I observed this in my environment, where I had two frameworks that used the
> same ExecutorID and then triggered a master failover. The master refuses to
> reregister the slave because it's not considering the owning-framework of the
> ExecutorID when computing ExecutorID uniqueness, and concludes (incorrectly)
> that there's an erroneous duplicate executor ID:
> {code}
> W1103 00:33:42.509891 19638 master.cpp:6008] Dropping re-registration of
> agent at slave(1)@10.2.0.7:5051 because it sent an invalid re-registration:
> Executor has a duplicate ExecutorID 'default'
> {code}
> (yes, "default" is probably a terrible name for an ExecutorID - that's a
> separate discussion!)
> /cc [~neilc]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
