@InterfaceAudience.Public @InterfaceStability.Evolving public enum ReservationRequestInterpreter extends Enum<ReservationRequestInterpreter>
ReservationRequests
within one ReservationDefinition
(from
least constraining to most constraining).Enum Constant and Description |
---|
R_ALL
Requires that ALL of the
ReservationRequest submitted as part of a
ReservationDefinition are satisfied for the overall
ReservationDefinition to be satisfied. |
R_ANY
Requires that exactly ONE among the
ReservationRequest submitted as
of a ReservationDefinition is satisfied to satisfy the overall
ReservationDefinition . |
R_ORDER
Requires that ALL of the
ReservationRequest submitted as part of a
ReservationDefinition are satisfied for the overall
ReservationDefinition to be satisfied. |
R_ORDER_NO_GAP
Requires that ALL of the
ReservationRequest submitted as part of a
ReservationDefinition are satisfied for the overall
ReservationDefinition to be satisfied. |
Modifier and Type | Method and Description |
---|---|
static ReservationRequestInterpreter |
valueOf(String name)
Returns the enum constant of this type with the specified name.
|
static ReservationRequestInterpreter[] |
values()
Returns an array containing the constants of this enum type, in
the order they are declared.
|
public static final ReservationRequestInterpreter R_ANY
ReservationRequest
submitted as
of a ReservationDefinition
is satisfied to satisfy the overall
ReservationDefinition
.
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 <32GB,16core> container for 10min, or 16 <2GB,1core> containers for 15min, the ReservationAgent will decide which one of the two it is best for the system to place.
public static final ReservationRequestInterpreter R_ALL
ReservationRequest
submitted as part of a
ReservationDefinition
are satisfied for the overall
ReservationDefinition
to be satisfied. No constraints are imposed
on the temporal ordering of the allocation used to satisfy the
ResourceRequests.
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 <8GB,4core> for 10min, and a reservation R2: with 2 <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.
public static final ReservationRequestInterpreter R_ORDER
ReservationRequest
submitted as part of a
ReservationDefinition
are satisfied for the overall
ReservationDefinition
to be satisfied. Moreover, it imposes a
strict temporal ordering on the allocation used to satisfy the
ReservationRequest
s. The allocations satisfying the
ReservationRequest
in position k must strictly precede the
allocations for the 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).
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 <1GB,1core> for 20min), and its output is consumed by a second job described by a ReservationDefinition R2 (5 x <1GB,1core>) for 50min). R2 allocation cannot overlap R1, as R2 models a job depending on the output of the job modeled by R1.
public static final ReservationRequestInterpreter R_ORDER_NO_GAP
ReservationRequest
submitted as part of a
ReservationDefinition
are satisfied for the overall
ReservationDefinition
to be satisfied. Moreover, it imposes a
strict temporal ordering on the allocation used to satisfy the
ReservationRequest
s. It imposes a strict temporal ordering on the
allocation used to satisfy the ReservationRequest
s. The allocations
satisfying the ReservationRequest
in position k must strictly
precede the allocations for the 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
ReservationRequest
at position k must be exactly preceding the
first instant in time of the 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).public static ReservationRequestInterpreter[] values()
for (ReservationRequestInterpreter c : ReservationRequestInterpreter.values()) System.out.println(c);
public static ReservationRequestInterpreter valueOf(String name)
name
- the name of the enum constant to be returned.IllegalArgumentException
- if this enum type has no constant with the specified nameNullPointerException
- if the argument is nullCopyright © 2023 Apache Software Foundation. All rights reserved.