[ 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)