@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
ResourceRequeusts.
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
ReservationRequests. 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
ReservationRequests. It imposes a strict temporal ordering on the
allocation used to satisfy the ReservationRequests. 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 © 2016 Apache Software Foundation. All Rights Reserved.