[jira] [Comment Edited] (MESOS-5131) DRF allocator crashes master with CHECK when resource is incorrect

["Zhitao Li (JIRA)" <ji...@apache.org>]

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

Zhitao Li edited comment on MESOS-5131 at 4/6/16 10:03 PM:
-----------------------------------------------------------

+1 to check that logic in _forwardOversubscribed. I think this is what I meant for "incorrect resource is not sent from agent", am I correct?


was (Author: zhitao):
+1 to check that logic in _forwardOversubscribed.

Still, I feel like adding error handling to the entire call chain of {{forwardOversubscribed()}} and reject the mesos slave is much better and safer handling, because we should not allow any rogue agent to trigger master crash loop.

> DRF allocator crashes master with CHECK when resource is incorrect
> ------------------------------------------------------------------
>
>                 Key: MESOS-5131
>                 URL: https://issues.apache.org/jira/browse/MESOS-5131
>             Project: Mesos
>          Issue Type: Bug
>          Components: allocation, oversubscription
>            Reporter: Zhitao Li
>            Priority: Critical
>
> We were testing a custom resource estimator which broadcasts oversubscribed resources, but they are not marked as "revocable".
> This unfortunately triggered the following check in hierarchical allocator:
> {quote}
> void HierarchicalAllocatorProcess::updateSlave(     
>   // Check that all the oversubscribed resources are revocable.
>   CHECK_EQ(oversubscribed, oversubscribed.revocable());
> {quote}
> This definitely shouldn't happen in production cluster. IMO, we should do both of following:
> 1. Make sure incorrect resource is not sent from agent (even crash agent process is better);
> 2. Decline agent registration if it's resources is incorrect, or even tell it to shutdown, and possibly remove this check.



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