hadoop ReservationRequestInterpreter 源码

haddop ReservationRequestInterpreter 代码

文件路径：/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api/src/main/java/org/apache/hadoop/yarn/api/records/ReservationRequestInterpreter.java

/**
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.hadoop.yarn.api.records;

import org.apache.hadoop.classification.InterfaceAudience.Public;
import org.apache.hadoop.classification.InterfaceStability.Evolving;

/**
 * Enumeration of various types of dependencies among multiple
 * {@link ReservationRequests} within one {@link ReservationDefinition} (from
 * least constraining to most constraining).
 */
@Public
@Evolving
public enum ReservationRequestInterpreter {
  /**
   * Requires that exactly ONE among the {@link ReservationRequest} submitted as
   * of a {@link ReservationDefinition} is satisfied to satisfy the overall
   * {@link ReservationDefinition}.
   * <p>
   * WHEN TO USE THIS: This is useful when the user have multiple equivalent
   * ways to run an application, and wants to expose to the ReservationAgent
   * such flexibility. For example an application could use one
   * {@literal <32GB,16core>} container for 10min, or 16 {@literal <2GB,1core>}
   * containers for 15min, the ReservationAgent will decide which one of the
   * two it is best for the system to place.
   */
  R_ANY,

  /**
   * Requires that ALL of the {@link ReservationRequest} submitted as part of a
   * {@link ReservationDefinition} are satisfied for the overall
   * {@link ReservationDefinition} to be satisfied. No constraints are imposed
   * on the temporal ordering of the allocation used to satisfy the
   * ResourceRequests.
   * <p>
   * WHEN TO USE THIS: This is useful to capture a scenario in which the user
   * cares for multiple ReservationDefinition to be all accepted, or none. For
   * example, a user might want a reservation R1: with 10 x
   * {@literal <8GB,4core>} for 10min, and a reservation R2:
   * with 2 {@literal <1GB,1core>} for 1h, and only if both are satisfied
   * the workflow run in this reservation succeeds. The key differentiator
   * from ALL and ORDER, ORDER_NO_GAP, is that ALL imposes no restrictions
   * on the relative allocations used to place R1 and R2 above.
   */
  R_ALL,

  /**
   * Requires that ALL of the {@link ReservationRequest} submitted as part of a
   * {@link ReservationDefinition} are satisfied for the overall
   * {@link ReservationDefinition} to be satisfied. Moreover, it imposes a
   * strict temporal ordering on the allocation used to satisfy the
   * {@link ReservationRequest}s. The allocations satisfying the
   * {@link ReservationRequest} in position k must strictly precede the
   * allocations for the {@link ReservationRequest} at position k+1. No
   * constraints are imposed on temporal gaps between subsequent allocations
   * (the last instant of the previous allocation can be an arbitrary long
   * period of time before the first instant of the subsequent allocation).
   * <p>
   * WHEN TO USE THIS: Like ALL this requires all ReservationDefinitions to be
   * placed, but it also imposes a time ordering on the allocations used. This
   * is important if the ReservationDefinition(s) are used to describe a
   * workflow with inherent inter-stage dependencies. For example, a first job
   * runs in a ReservaitonDefinition R1 (10 x {@literal <1GB,1core>}
   * for 20min), and its output is consumed by a second job described by
   * a ReservationDefinition R2 (5 x {@literal <1GB,1core>}) for 50min).
   * R2 allocation cannot overlap R1, as R2 models a job depending on
   * the output of the job modeled by R1.
   */
  R_ORDER,

  /**
   * Requires that ALL of the {@link ReservationRequest} submitted as part of a
   * {@link ReservationDefinition} are satisfied for the overall
   * {@link ReservationDefinition} to be satisfied. Moreover, it imposes a
   * strict temporal ordering on the allocation used to satisfy the
   * {@link ReservationRequest}s. It imposes a strict temporal ordering on the
   * allocation used to satisfy the {@link ReservationRequest}s. The allocations
   * satisfying the {@link ReservationRequest} in position k must strictly
   * precede the allocations for the {@link ReservationRequest} at position k+1.
   * Moreover it imposes a "zero-size gap" between subsequent allocations, i.e.,
   * the last instant in time of the allocations associated with the
   * {@link ReservationRequest} at position k must be exactly preceding the
   * first instant in time of the {@link ReservationRequest} at position k+1.
   * Time ranges are interpreted as [a,b) inclusive left, exclusive right.
   * 
   * WHEN TO USE THIS: This is a stricter version of R_ORDER, which allows no
   * gaps between the allocations that satisfy R1 and R2. The use of this is
   * twofold: 1) prevent long gaps between subsequent stages that produce very
   * large intermediate output (e.g., the output of R1 is too large to be kept
   * around for long before the job running in R2 consumes it, and disposes of
   * it), 2) if the job being modeled has a time-varying resource need, one can
   * combine multiple ResourceDefinition each approximating a portion of the job
   * execution (think of using multiple rectangular bounding boxes to described
   * an arbitrarily shaped area). By asking for no-gaps we guarantee
   * "continuity" of resources given to this job. This still allow for some
   * flexibility, as the entire "train" of allocations can be moved rigidly back
   * or forth within the start-deadline time range (if there is slack).
   * 
   */
  R_ORDER_NO_GAP

}

相关信息

hadoop 源码目录

相关文章

hadoop AMCommand 源码

hadoop AllocationTagNamespaceType 源码

hadoop ApplicationAccessType 源码

hadoop ApplicationAttemptId 源码

hadoop ApplicationAttemptReport 源码

hadoop ApplicationId 源码

hadoop ApplicationReport 源码

hadoop ApplicationResourceUsageReport 源码

hadoop ApplicationSubmissionContext 源码

hadoop ApplicationTimeout 源码