-
Notifications
You must be signed in to change notification settings - Fork 1
Execution Descriptions
Home - Features - Architecture - Execution - Scenarios - Use-Cases - API
The Troy level workload descriptions are discussed as part of the NGMW Workload Description stack, in the NGMW wiki.
The workload is submitted to TROY in the form of:
- a set of task descriptions;
- a specification of the relationship(s) among those tasks.
Once received, the workload is evaluated and elaborated so that its tasks can eventually be executed on a DCI.
-
Application layer:
- Decomposition: A workload is decomposed into a set of tasks descriptions and a relation R that describes the relationship among tasks.
-
Workload Manager:
- Translation: One or more task description is translated into (one or more) *unit description (* = Compute, Data, Network).
- Description: One or more pilot is described.
- Pilot Scheduling: Scheduling Pilots on Resources.
- Instantiation: One or more pilot description is instantiated into a type of pilot instance (e.g. Job or VM).
- Binding: One or more *unit description is bound to a pilot description or pilot instance.
- Submission: One or more *unit description is submitted to the pilot framework for execution.
-
Pilot layer:
- Execution: One or more *unit description is executed by means of a pilot framework.
The operations of the WM are executed in different temporal order, depending on the given scenario. Each trace describes a temporal order of a set of operations that should be implemented by means of the WM. Each operation may have multiple implementations, depending on the temporal order in which it is executed.
Syntax:
-
# - # = temporal step
-
# | # = temporal concurrency
-
() = Block
-
Trace a: (2 - 5) - (9 - 10) - 13
-
Trace b: (3 - 4) - (6 - 10) - 13
-
Trace c: (2 - 5) - (8 - 11) - 13
-
Trace d: (3 - 4) - (7 - 11) - 13
-
Trace e: 8 | (2 - 6) - 13
-
Trace f: (3 - 8) - (2 - 6) - 13
Type | Description |
---|---|
Workload Description | ({Task Description}, R) with R = relationship among tasks |
Task Description | (Duration, # Cores, Executable, Input File) |
*Unit Description | (Duration, # Cores, Executable, Arguments, Environment, Output File, Error File) |
Resource Description | See Bundle API |
Pilot Description | (Service URI, # Cores, Working Directory, Walltime) |
Bind | () |
Pilot Instance | (Coordination Service URI) |
Submission | () |
Execution Output | () |
Trace a | Trace b |
---|---|
Trace c | Trace d |
Trace e | Trace f |
Issues:
- Do traces apply to single tasks, single stages, set of tasks and/or set of stages? We decided to
- Related: is the task the desirable minimal unit of our design? If so, we might have a task of a stage that is early-bound while another one, of the same stage, is late bound. Does this make sense? Too granular? In order to answer to this question I think we need scenarios.
- Constraints: List all the constraints about the temporal composition of operations.