hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Omkar Vinit Joshi (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-948) RM should validate the release container list before actually releasing them
Date Fri, 26 Jul 2013 23:03:49 GMT

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

Omkar Vinit Joshi commented on YARN-948:
----------------------------------------

bq. If some of the release requests are valid and some are invalid, we should accept the valid
requests?
bq. If so, please modify the test to validate these multiple success/failure cases.
Probably not. We should have same behavior like "ask". thoughts?

bq. To indicate its non-scheduler-specificity, validateContainerReleaseRequest() could be
in RMServerUtils?
Other validate calls are present in SchedulerUtils. Let me know if I should move all or this?

bq. Shouldn't be using InvalidResourceRequestException for invalid release-requests. Don't
know if we are over-killing it, but a new exception?
Yeah thought about it but but then sticked to it don't think we should have separate exception
for this scenario. Let me know I will modify.
                
> RM should validate the release container list before actually releasing them
> ----------------------------------------------------------------------------
>
>                 Key: YARN-948
>                 URL: https://issues.apache.org/jira/browse/YARN-948
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Omkar Vinit Joshi
>            Assignee: Omkar Vinit Joshi
>         Attachments: YARN-948-20130724.patch
>
>
> At present we are blinding passing the allocate request containing containers to be released
to the scheduler. This may result into one application releasing another application's container.
> {code}
>   @Override
>   @Lock(Lock.NoLock.class)
>   public Allocation allocate(ApplicationAttemptId applicationAttemptId,
>       List<ResourceRequest> ask, List<ContainerId> release, 
>       List<String> blacklistAdditions, List<String> blacklistRemovals) {
>     FiCaSchedulerApp application = getApplication(applicationAttemptId);
> ....
> ....
>     // Release containers
>     for (ContainerId releasedContainerId : release) {
>       RMContainer rmContainer = getRMContainer(releasedContainerId);
>       if (rmContainer == null) {
>          RMAuditLogger.logFailure(application.getUser(),
>              AuditConstants.RELEASE_CONTAINER, 
>              "Unauthorized access or invalid container", "CapacityScheduler",
>              "Trying to release container not owned by app or with invalid id",
>              application.getApplicationId(), releasedContainerId);
>       }
>       completedContainer(rmContainer,
>           SchedulerUtils.createAbnormalContainerStatus(
>               releasedContainerId, 
>               SchedulerUtils.RELEASED_CONTAINER),
>           RMContainerEventType.RELEASED);
>     }
> {code}
> Current checks are not sufficient and we should prevent this..... thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message