001/** 002 * Licensed to the Apache Software Foundation (ASF) under one 003 * or more contributor license agreements. See the NOTICE file 004 * distributed with this work for additional information 005 * regarding copyright ownership. The ASF licenses this file 006 * to you under the Apache License, Version 2.0 (the 007 * "License"); you may not use this file except in compliance 008 * with the License. You may obtain a copy of the License at 009 * 010 * http://www.apache.org/licenses/LICENSE-2.0 011 * 012 * Unless required by applicable law or agreed to in writing, software 013 * distributed under the License is distributed on an "AS IS" BASIS, 014 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 015 * See the License for the specific language governing permissions and 016 * limitations under the License. 017 */ 018 019package org.apache.hadoop.yarn.api.records; 020 021import org.apache.hadoop.classification.InterfaceAudience.Public; 022import org.apache.hadoop.classification.InterfaceStability.Evolving; 023 024/** 025 * Enumeration of various types of dependencies among multiple 026 * {@link ReservationRequests} within one {@link ReservationDefinition} (from 027 * least constraining to most constraining). 028 */ 029@Public 030@Evolving 031public enum ReservationRequestInterpreter { 032 /** 033 * Requires that exactly ONE among the {@link ReservationRequest} submitted as 034 * of a {@link ReservationDefinition} is satisfied to satisfy the overall 035 * {@link ReservationDefinition}. 036 * <p> 037 * WHEN TO USE THIS: This is useful when the user have multiple equivalent 038 * ways to run an application, and wants to expose to the ReservationAgent 039 * such flexibility. For example an application could use one 040 * {@literal <32GB,16core>} container for 10min, or 16 {@literal <2GB,1core>} 041 * containers for 15min, the ReservationAgent will decide which one of the 042 * two it is best for the system to place. 043 */ 044 R_ANY, 045 046 /** 047 * Requires that ALL of the {@link ReservationRequest} submitted as part of a 048 * {@link ReservationDefinition} are satisfied for the overall 049 * {@link ReservationDefinition} to be satisfied. No constraints are imposed 050 * on the temporal ordering of the allocation used to satisfy the 051 * ResourceRequests. 052 * <p> 053 * WHEN TO USE THIS: This is useful to capture a scenario in which the user 054 * cares for multiple ReservationDefinition to be all accepted, or none. For 055 * example, a user might want a reservation R1: with 10 x 056 * {@literal <8GB,4core>} for 10min, and a reservation R2: 057 * with 2 {@literal <1GB,1core>} for 1h, and only if both are satisfied 058 * the workflow run in this reservation succeeds. The key differentiator 059 * from ALL and ORDER, ORDER_NO_GAP, is that ALL imposes no restrictions 060 * on the relative allocations used to place R1 and R2 above. 061 */ 062 R_ALL, 063 064 /** 065 * Requires that ALL of the {@link ReservationRequest} submitted as part of a 066 * {@link ReservationDefinition} are satisfied for the overall 067 * {@link ReservationDefinition} to be satisfied. Moreover, it imposes a 068 * strict temporal ordering on the allocation used to satisfy the 069 * {@link ReservationRequest}s. The allocations satisfying the 070 * {@link ReservationRequest} in position k must strictly precede the 071 * allocations for the {@link ReservationRequest} at position k+1. No 072 * constraints are imposed on temporal gaps between subsequent allocations 073 * (the last instant of the previous allocation can be an arbitrary long 074 * period of time before the first instant of the subsequent allocation). 075 * <p> 076 * WHEN TO USE THIS: Like ALL this requires all ReservationDefinitions to be 077 * placed, but it also imposes a time ordering on the allocations used. This 078 * is important if the ReservationDefinition(s) are used to describe a 079 * workflow with inherent inter-stage dependencies. For example, a first job 080 * runs in a ReservaitonDefinition R1 (10 x {@literal <1GB,1core>} 081 * for 20min), and its output is consumed by a second job described by 082 * a ReservationDefinition R2 (5 x {@literal <1GB,1core>}) for 50min). 083 * R2 allocation cannot overlap R1, as R2 models a job depending on 084 * the output of the job modeled by R1. 085 */ 086 R_ORDER, 087 088 /** 089 * Requires that ALL of the {@link ReservationRequest} submitted as part of a 090 * {@link ReservationDefinition} are satisfied for the overall 091 * {@link ReservationDefinition} to be satisfied. Moreover, it imposes a 092 * strict temporal ordering on the allocation used to satisfy the 093 * {@link ReservationRequest}s. It imposes a strict temporal ordering on the 094 * allocation used to satisfy the {@link ReservationRequest}s. The allocations 095 * satisfying the {@link ReservationRequest} in position k must strictly 096 * precede the allocations for the {@link ReservationRequest} at position k+1. 097 * Moreover it imposes a "zero-size gap" between subsequent allocations, i.e., 098 * the last instant in time of the allocations associated with the 099 * {@link ReservationRequest} at position k must be exactly preceding the 100 * first instant in time of the {@link ReservationRequest} at position k+1. 101 * Time ranges are interpreted as [a,b) inclusive left, exclusive right. 102 * 103 * WHEN TO USE THIS: This is a stricter version of R_ORDER, which allows no 104 * gaps between the allocations that satisfy R1 and R2. The use of this is 105 * twofold: 1) prevent long gaps between subsequent stages that produce very 106 * large intermediate output (e.g., the output of R1 is too large to be kept 107 * around for long before the job running in R2 consumes it, and disposes of 108 * it), 2) if the job being modeled has a time-varying resource need, one can 109 * combine multiple ResourceDefinition each approximating a portion of the job 110 * execution (think of using multiple rectangular bounding boxes to described 111 * an arbitrarily shaped area). By asking for no-gaps we guarantee 112 * "continuity" of resources given to this job. This still allow for some 113 * flexibility, as the entire "train" of allocations can be moved rigidly back 114 * or forth within the start-deadline time range (if there is slack). 115 * 116 */ 117 R_ORDER_NO_GAP 118 119}