[
https://issues.apache.org/jira/browse/MESOS-7308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971801#comment-15971801
]
Anindya Sinha edited comment on MESOS-7308 at 5/11/17 8:23 PM:
---------------------------------------------------------------
RRs published for review:
https://reviews.apache.org/r/58485/
https://reviews.apache.org/r/59195/
https://reviews.apache.org/r/58486/
was (Author: anindya.sinha):
RRs published for review:
https://reviews.apache.org/r/58485/
https://reviews.apache.org/r/58486/
https://reviews.apache.org/r/58487/
> Race condition in `updateAllocation()` on DESTORY of a shared volume.
> ---------------------------------------------------------------------
>
> Key: MESOS-7308
> URL: https://issues.apache.org/jira/browse/MESOS-7308
> Project: Mesos
> Issue Type: Bug
> Reporter: Anindya Sinha
> Assignee: Anindya Sinha
> Labels: persistent-volumes
>
> When a {{DESTROY}} (for shared volume) is processed in the master actor, we
> rescind pending offers to which the volume to be destroyed is already offered
> to. Before allocator executes the {{updateAllocation()}} API, offers with the
> same shared volume can be sent to frameworks since the destroyed shared
> volume is not removed from {{slaves.total}} till {{updateAllocation()}}
> completes. As a result, the following check can fail:
> {code}
> CHECK_EQ(
> frameworkAllocation.flatten().createStrippedScalarQuantity(),
> updatedFrameworkAllocation.flatten().createStrippedScalarQuantity());
> {code}
> We need to address this condition by not failing the {{CHECK_EQ}}, and also
> ensuring that the master's state is restored to honor the {{DESTROY}} of the
> shared volume.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
