Attached ver.1 patch for review, it is fully functioned, has all changes needed in my mind right now. Will clean up more in the next patch for things like unnecessary comments, indent, etc.

-1 overall

This message was automatically generated.

Attached ver.2 patch.

-1 overall

This message was automatically generated.

• why volatile

      private volatile BlockingQueue<ResourceCommitRequest<FiCaSchedulerApp, FiCaSchedulerNode>>
          backlogs = new LinkedBlockingQueue<>();
  

• 1 millisecond ? is this intentional ?

              // Don't run schedule if we have some pending backlogs already
              if (cs.getAsyncSchedulingPendingBacklogs() > 100) {
                Thread.sleep(1);
  

• getReservedSchedulerKey vs getAllocatedSchedulerKey: looks like the same ?
• allocateContainersToNode: remove withNodeHeartbeat flag. Make the other caller call "allocateContainersToNode(PlacementSet<FiCaSchedulerNode> ps" directly
• "allocateContainersToNode(PlacementSet<FiCaSchedulerNode> ps ": maybe use lookAtSingleNode boolean to fork the code path. Make a separate method.

• the first if condition is probably not needed.

      if (null != allocated || null != reserved || (null != released && !released
          .isEmpty())) {
        List<ContainerAllocationContext<FiCaSchedulerApp, FiCaSchedulerNode>>
            allocationsList = null;
        if (allocated != null) {
          allocationsList = new ArrayList<>();
          allocationsList.add(allocated);
        }
  
        List<ContainerAllocationContext<FiCaSchedulerApp, FiCaSchedulerNode>>
            reservationsList = null;
        if (reserved != null) {
          reservationsList = new ArrayList<>();
          reservationsList.add(reserved);
        }
  
        return new ResourceCommitRequest<>(allocationsList, reservationsList,
            released);
      }
  

• Fix unnecessary format changes in CapacityScheduler
• Below null check is unnecessary

              RMContainer fromReservedContainer = null;
              if (allocation.getAllocateFromReservedContainer() != null) {
                fromReservedContainer =
                    allocation.getAllocateFromReservedContainer()
                        .getRmContainer();
              }
  

• This seems inconsistent with following code which will not add reserved resource back.

            // Do we have enough space on this node?
            Resource availableResource = Resources.clone(
                schedulerContainer.getSchedulerNode().getUnallocatedResource());
            if (allocation.getAllocateFromReservedContainer() != null) {
              Resources.addTo(availableResource,
                  allocation.getAllocateFromReservedContainer()
                      .getRmContainer().getReservedResource());
            }
  

• may be we can check anythingAllocatedOrReserved and getAllocateFromReservedContainer outside of accept so that they do need to be checked for every queue in the path.

      boolean accepted = true;
      if (!reReservation) {
        // Check parent
        accepted = getCSLeafQueue().accept(cluster, request);
      }
  
  

• should these methods be synchronized for consistency

    public void incUnconfirmedRes(Resource res) {
      unconfirmedAllocatedMem.addAndGet(res.getMemorySize());
      unconfirmedAllocatedVcores.addAndGet(res.getVirtualCores());
    }
  
    public void decUnconfirmedRes(Resource res) {
      unconfirmedAllocatedMem.addAndGet(-res.getMemorySize());
      unconfirmedAllocatedVcores.addAndGet(-res.getVirtualCores());
    }
   

• Too many data structures which wrapps container related info with similar names: CSAssignment, ContainerAllocation, ContainerAllocationContext, SchedulerContainer.. could you consolidate these ?
• SchedulingPlacementSet has a bunch unused methods and introduced unused class ResourceRequestUpdateResult, can we add them when needed ?
• rename allocationResult.updatedContainer properly ? or add comments to what this field is used for
• Add comments to what preCheckForPlacementSet does
• preCheckForSingleNode -> checkIfNodeBlackListed
• change getFinishedStatus to isCompleted
• I think this needs to be done in accept ?

      // Inform the application it is about to get a scheduling opportunity
      // TODO, we may need to revisit here to see if we should add scheduling
      // opportunity here
      application.addSchedulingOpportunity(schedulerKey);
   

• FiCaSchedulerApp#toBeRemovedIncRequests, why is this field moved to this class ? now the toBeRemovedIncRequests will be removed on allocate API only

Thanks Jian He for reviews,

1 millisecond ? is this intentional ?

This is to avoid busy loop and pinned on CPU, sleep 1 ms can make CPU usage close to 0%.

getReservedSchedulerKey vs getAllocatedSchedulerKey: looks like the same ?

Yeah they're similiar, since they're not new from this patch, I prefer to address this separately.

Too many data structures which wrapps container related info with similar names: CSAssignment, ContainerAllocation, ContainerAllocationContext, SchedulerContainer.. could you consolidate these ?

Agree, but I prefer to address them separately, CSAssignment/ContainerAllocation are not introduced by this patch. Relation between ContainerAllocationContext and SchedulerContainer is has-more, so we don't need to consolidate the latter two.

SchedulingPlacementSet has a bunch unused methods and introduced unused class ResourceRequestUpdateResult, can we add them when needed ?

That is part of the SchedulingPlacementSet definition, I prefer to keep them here. My next patch will start using it.

Addressed all other comments. (ver.3)

-1 overall

This message was automatically generated.

Attached ver.4 patch, fixed UT failures and javac warnings.

-1 overall

This message was automatically generated.

• remove this?

          /*
          FIXME
          application
              .getCSLeafQueue()
              .getOrderingPolicy()
              .containerAllocated(application,
                  application.getRMContainer(updatedContainer.getId()));
          */
  

• When stop, if the thread is interrupted, the else condition will make the thread continue to run. the join in stop will always timeout.

            if (!runSchedules.get() && !Thread.currentThread().isInterrupted()) {
              Thread.sleep(100);
            } else{
              // Don't run schedule if we have some pending backlogs already
              if (cs.getAsyncSchedulingPendingBacklogs() > 100) {
                Thread.sleep(1);
              } else{
                schedule(cs);
              }
            }
          } catch (InterruptedException ie) {
            // Do nothing
          }
  

• the withNodeHeartbeat flag is not needed, because it's already checked in the caller

    private boolean canAllocateMore(CSAssignment assignment,
        boolean withNodeHeartbeat) {
  

• how about check whether "getNode(node.getNodeID())" equals to null, I feel that's easier to reason for a removed node

      // Backward compatible way to make sure previous behavior which allocation
      // driven by node heartbeat works.
      if (getNode(node.getNodeID()) != node)
  

• This if condition can be merged into previous "if (reservedContainer != null) {" condition, as they are the same.

      // Do not schedule if there are any reservations to fulfill on the node
      if (node.getReservedContainer() != null) {
        if (LOG.isDebugEnabled()) {
          LOG.debug("Skipping scheduling since node " + node.getNodeID()
              + " is reserved by application " + node.getReservedContainer()
              .getContainerId().getApplicationAttemptId());
        }
        return null;
      }
   

• canSchedule flag is not needed, the previuous if condition can just return direclty

       if (!canSchedule) {
        if (LOG.isDebugEnabled()) {
          LOG.debug("This node or this node partition doesn't have available or"
              + "killable resource");
        }
        return null;
      }
  

• the canSchedule flag here is also not needed
  similarly,

      boolean canSchedule = false;
  
      // When this time look at multiple nodes, try schedule if the
      // partition has any available resource
      if (root.getQueueCapacities().getUsedCapacity(ps.getPartition()) < 1.0f
          || preemptionManager.getKillableResource(
          CapacitySchedulerConfiguration.ROOT, ps.getPartition()) != Resources
          .none()) {
        canSchedule = true;
      }
  
      if (!canSchedule) {
        if (LOG.isDebugEnabled()) {
          LOG.debug("This node or this node partition doesn't have available or"
              + "killable resource");
        }
        return null;
      }
  

• Looks like one behavior change is that previously on node heartbeat, we always satisfy reservedContainer first, now in async scheduling, it's not the case any more ?
• this if check is not needed, beacuse it's already checked in the caller

    private CSAssignment allocateContainersOnMultiNodes(
        PlacementSet<FiCaSchedulerNode> ps) {
      if (rmContext.isWorkPreservingRecoveryEnabled() && !rmContext
          .isSchedulerReadyForAllocatingContainers()) {
        return null;
      }
  

• PlacementSet, placement is an abstract name, how about NodeSet to be more concret?
  -PlacementSetUtils.getSingleNode -> hasSingleNode
• ContainerAllocationContext -> ContainerAllocationProposal

• nodePartition parameter is not needed, it can be inferred from 'node' parameter

    public SchedulerContainer(A app, N node, RMContainer rmContainer,
        String nodePartition, boolean allocated) {
  

• remove this method, a new method with the same name just makes it more confusing. And the other getSchedulerContainer method with false condition is already being used in some places.

    private SchedulerContainer<FiCaSchedulerApp, FiCaSchedulerNode> getSchedulerContainer(
        RMContainer rmContainer) {
      return getSchedulerContainer(rmContainer, false);
    }
  

• These two if conditidions code are duplicated, can be moved out side

            if (updateUnconfirmedAllocatedResource) {
              app.decUnconfirmedRes(request.getTotalAllocatedResource());
            }
            LOG.info("Allocation proposal accepted");
          } else{
            if (updateUnconfirmedAllocatedResource) {
              app.decUnconfirmedRes(request.getTotalAllocatedResource());
            }
  

• remove this
  // If we do assign, remove the queue and re-insert in-order to re-sort\
• In LeafQueue#updateCurrentResourceLimits, multiple threads will update cachedResourceLimitsForHeadroom without synchronization
• Fix indetation

        if (null != application) {
        ActivitiesLogger.APP.startAppAllocationRecording(activitiesManager,
            node.getNodeID(), SystemClock.getInstance().getTime(), application);
        CSAssignment assignment = application.assignContainers(clusterResource,
            ps, currentResourceLimits, schedulingMode, reservedContainer);
        return assignment;
        }
  

• LeafQueeu#handleReservedContainer -> allocateReservedContainer
• SchedulerApplicationAttempt#incNumAllocatedContainers, all the locality statistics functionality are removed ?

Thanks Jian He for the thorough review!

how about check whether "getNode(node.getNodeID())" equals to null, I feel that's easier to reason for a removed node

It is also possible that ref to the node is changed, for example, node resource updated. In that case, we may need to skip such node for safety.

This if condition can be merged into previous "if (reservedContainer != null) {" condition, as they are the same.

No we cannot do this merge, because it is possible that in the previous reservedContainer != null if, we reserve a new container so the check is not valid.

Looks like one behavior change is that previously on node heartbeat, we always satisfy reservedContainer first, now in async scheduling, it's not the case any more ?

It is still the same, if you look at allocateContainerOnSingleNode, we try to satisify reserved contaienr first.

PlacementSet, placement is an abstract name, how about NodeSet to be more concret?

I would prefer use "PlacementSet", since it is for "placement", we could add more information to it, for example, racks.

PlacementSetUtils.getSingleNode -> hasSingleNode

But what we need to do is to return the node if it is a single-node-placement-set, I think this name is better

nodePartition parameter is not needed, it can be inferred from 'node' parameter

The original purpose adding the partition is, the partition of node could be updated in between of proposal proposed and applied, it will be used to check if we should reject the proposal when partition of the node changed. I have a separate "TODO" in FiCaSchedulerApp:

// TODO, make sure all node labels are not changed

In LeafQueue#updateCurrentResourceLimits, multiple threads will update cachedResourceLimitsForHeadroom without synchronization

This is intentional: we want the resourceLimitsForHeadroom is up-to-date, it is possible that one thread has some inconsistency data, but it will be corrected soon by other threads. Since the resourceLimitsForHeadroom is only used to just give more hints to application, it should be fine.
And ResourceLimits is volatile, so it is safe as well.

SchedulerApplicationAttempt#incNumAllocatedContainers, all the locality statistics functionality are removed ?

Oh I missed that, will update it in the next iteration.

Addressed all the other comments

Uploaded patch ver.5

-1 overall

This message was automatically generated.

Rebased to latest trunk (006)

-1 overall

This message was automatically generated.

Attached ver.7 patch, fixed locality statistics and added one more test for that.

-1 overall

This message was automatically generated.

latest patch looks good to me

Sorry for pitching in late.

Patch and approaches looks really great. Thank you.

Some minor doubts/comments after a first round of scan

1. is AppSchedulingInfo#updateMetricsForAllocatedContainer need to be under lock, I think its safely invoked within a lock block? Do you have some plans to reuse this module later somewhere, if so its fine.
2. Every time AppSchedulingInfo#getSchedulingPlacementSet is invoked, a new SchedulingPlacementSet is created with all nodes iterator. Could we have an abstract class here so that we can maintain this code by keeping a basic impl for other non-used methods?
3. LeafQueue#apply, could we have a more fine grained lock for allocateResource and orderingPolicy. I think we do not worry about request object, correct? pls correct me if I am wrong.
4. Is it possible to keep the interfaces SchedulerContainer or ContainerAllocationProposal more read-only? I think it will help us keep interfaces more cleaner.
5. One doubt in ResourceCommitRequest. Why are we adding allocated/reserved resources to totalReleasedResource? Sorry, i didnt understand here.
I think i have only some more minor comments which i ll share in short while. Will make sure it ll not block the commit process

Thanks Jian He!

And thanks comments from Sunil G.

For 1)/3).
From my existing test result, the CPU time spent on write lock (which is under scheduler's accept/apply) is only a very small proportion comparing to the CPU time spent on read lock. It is around 3% to 10%. IAW, write lock is not a bottleneck, as of now, we cannot get a significant perf gain from the improvements in writelock. So I'd prefer to keep them as-is to just make it simpler.

For 2). Yeah you're correct, it is a part of my next patch, I plan to move resource-request related functionalities from AppSchedulingInfo to SchedulingPlacementSet. I will share my POC patch soon.

For 4). I'm not quite sure about what you meant, do you want to add comments to indicate it should be a read-only class or you want to remove writing APIs from these classes?

For 5). I think you were talking about these logics:

    for (ContainerAllocationProposal<A,N> c : this.containersToReserve) {
      Resources.addTo(totalReservedResource,
          c.getAllocatedOrReservedResource());
      for (SchedulerContainer<A,N> r : c.getToRelease()) {
        Resources.addTo(totalReleasedResource,
            r.getRmContainer().getAllocatedOrReservedResource());
      }
    }

For each allocated/reserved container, we can have a to-release containers : ContainerAllocationProposal#toRelease, which means we will kill/release these containers to allocate/reserve the given container. To distinguish these to-release containers from ResourceCommitRequest#toReleaseContainers. I call them "conditional release containers" : we will only release them when trying to allocate/reserve new resource.

And I think we need to account both of conditional/unconditional to-release containers to the total release-able resource.

Let me know if you have any comments.

Thanks,

For example continuous-reservation-looking/lazy-preemption.

Thanks Wangda Tan.

do you want to add comments to indicate it should be a read-only class or you want to remove writing APIs from these classes?

I was expecting to remove setter api's from this interface. Thoughts?

continuous-reservation-looking

I think the code is slightly complicated, but functionality seems fine. I am checking lazy-preemption now.

Sunil G, make sense.

I just uploaded ver.8 patch, which removed all set interfaces from new added APIs. And I also added a comment to ResourceCommitRequest constructor to explain the to-release resource behavior.

-1 overall

This message was automatically generated.

Thanks Wangda Tan for the update.

Few more general comments:

1. computeUserLimitAndSetHeadroom is invoked invoked from accept call chain and from assigneContainers. I think its fine provided the both gives similar computed data. With user-limit preemption improvement, i think if compute is done outside these scheduler call flow, such user-limit computation costs can be brought down.
2. In LeafQueue.accept,

        Resources.subtractFrom(usedResource,
            request.getTotalReleasedResource());

totalReleasedResource also include reserved resources too, correct. Do we need to decrement that? I am not very clear in this point here.

3. In CS#allocateContainerOnSingleNode, node.getReservedContainer() is checked two times (second time to handle error case). Could we handle in first block itself.
4. In FiCaSchedulerApp.accept,

• a reference for resourceRequests is kept and under failure updated back to schedulingInfo object. I do not feel its a clean implementation. I remember this change, but I feel we need not have to take a reference in app level, may be we can keep it in schedulingInfo and can be used the same during recovery.
• Method is very lengthy. We could take out logic like increase request etc. So it ll be more easier.
• readLock is mostly needed for increased request and for appSchedulingInfo. I think some optimizations here could be done separately in another ticket as improvement.
• preferring equals instead of if (fromReservedContainer != reservedContainerOnNode)

Also I have checked reservation continue scheduling and lazy-preemption in particular in this round. Generally both looks fine for me.

Thanks Sunil G for comments:

For 1), yes it looks like we're doing UL check twice, however, the second time only check one application instead of thousands of apps.
So the time spent on UL check for accept/apply is ignoreable from my performance tests.

For 2), we will not check allocation-from-reserved container by the outter if (...) check

For 3), Jian asked the same question, see my answer https://issues.apache.org/jira/browse/YARN-5716?focusedCommentId=15593292&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15593292:

No we cannot do this merge, because it is possible that in the previous reservedContainer != null if, we reserve a new container so the check is not valid.

For 4):

a reference for resourceRequests is kept and under failure updated back to schedulingInfo object. I do not feel its a clean implementation...

Actually we clone the ResourceRequest, and we need to check and make sure ResourceRequest is not changed or still required by the apps.

Method is very lengthy. We could take out logic like increase request etc. So it ll be more easier.

Done

readLock is mostly needed for increased request and for appSchedulingInfo. I think some optimizations here could be done separately in another ticket as improvement.

Yeah I agree, I would prefer to keep it as-is unless we find any performance issues.

preferring equals instead of if (fromReservedContainer != reservedContainerOnNode)

I intended to do that, I want to make sure two reserved container are pointed to the same instance.

Please check ver.9 patch

-1 overall

This message was automatically generated.

Thanks Wangda Tan for the clarifications. Makes sense. New patch looks fine for me too.

Attached ver.10 patch rebased to latest trunk, Rewrote tests for YARN-4963.

Ver.10 patch included unnecessary changes, attached ver.11.

-1 overall

This message was automatically generated.

-1 overall

This message was automatically generated.

Rebased to latest trunk (v12).

-1 overall

This message was automatically generated.

Rebased again, (ver.13)

-1 overall

This message was automatically generated.

we'll commit this soon, if no further comments

Committed to trunk , branch-2, thanks Wangda !

SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #10784 (See https://builds.apache.org/job/Hadoop-trunk-Commit/10784/)
YARN-5716. Add global scheduler interface definition and update (jianhe: rev de3b4aac561258ad242a3c5ed1c919428893fd4c)

• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/MockRM.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/ParentQueue.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestLeafQueue.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestCapacityScheduler.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/common/AssignmentInformation.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/CSAssignment.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/rmcontainer/RMContainerImpl.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/common/fica/FiCaSchedulerApp.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/allocator/IncreaseContainerAllocator.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/allocator/RegularContainerAllocator.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestParentQueue.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/CSQueue.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/common/ContainerAllocationProposal.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/common/SchedulerContainer.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/activities/ActivitiesLogger.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/AppSchedulingInfo.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/common/ResourceCommitRequest.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestCapacitySchedulerAsyncScheduling.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestUtils.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/placement/ResourceRequestUpdateResult.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/CapacitySchedulerConfiguration.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/fifo/FifoScheduler.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/CapacityScheduler.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/policy/FairOrderingPolicy.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/allocator/ContainerAllocator.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/placement/PlacementSet.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/activities/ActivitiesManager.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/placement/PlacementSetUtils.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/policy/FifoOrderingPolicyForPendingApps.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/allocator/ContainerAllocation.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/common/ResourceAllocationCommitter.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/SchedulerApplicationAttempt.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/policy/FifoOrderingPolicy.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestContainerAllocation.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/fifo/FifoAppAttempt.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/policy/AbstractComparatorOrderingPolicy.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/allocator/AbstractContainerAllocator.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/webapp/TestRMWebServicesSchedulerActivities.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/rmcontainer/RMContainer.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestContainerResizing.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestChildQueueOrder.java
• (edit) hadoop-yarn-project/hadoop-yarn/dev-support/findbugs-exclude.xml
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/placement/SchedulingPlacementSet.java
• (add) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/placement/SimplePlacementSet.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/TestReservations.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestClientRMService.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/AbstractCSQueue.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/TestSchedulerHealth.java
• (edit) hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/capacity/LeafQueue.java