feat: armonik domain definitions aep#47
Conversation
some changes definition of metadata changes Update AEP/aep-0000y.md Co-authored-by: qdelamea-aneo <134614217+qdelamea-aneo@users.noreply.github.com> Update AEP/aep-0000y.md Co-authored-by: qdelamea-aneo <134614217+qdelamea-aneo@users.noreply.github.com> last corrections
857954a to
1e4a083
Compare
|
|
||
| ## Scheduling agent | ||
|
|
||
| Containerized software cohabiting with a worker, running a specific algorithm to determine which tasks its associated workers should perform, scheduling tasks on the workers and monitoring their execution. It also manages all interactions between the worker and the databases (retrieving/saving data, creating new tasks, etc.), as well as managing workers errors and retrying/resubmitting failed tasks when necessary. A scheduling agent, like a worker, exists within a single partition. |
There was a problem hiding this comment.
| Containerized software cohabiting with a worker, running a specific algorithm to determine which tasks its associated workers should perform, scheduling tasks on the workers and monitoring their execution. It also manages all interactions between the worker and the databases (retrieving/saving data, creating new tasks, etc.), as well as managing workers errors and retrying/resubmitting failed tasks when necessary. A scheduling agent, like a worker, exists within a single partition. | |
| Containerized software cohabiting with a worker inside a pod, running the main algorithm of the orchestrator which will determine the tasks that the linked worker will perform. It will schedul the task on the workers and monitor their execution. It also manages all interactions between the worker and the databases (retrieving/saving data, creating new tasks, etc.), as well as managing workers errors and retrying/resubmitting failed tasks when necessary. A scheduling agent, like a worker, exists within a single partition. |
There was a problem hiding this comment.
Maybe we shouldn't use "pod" once we aim to go bare metal soon and it is mostly associated with k3s
|
|
||
| ## Partition | ||
|
|
||
| Logical segmentation of the cluster's pool of machines to distribute workloads according to usage. This feature is provided and handled by ArmoniK. |
There was a problem hiding this comment.
Perhaps we should precise that this the creation is done by Armonik only at deployement stage (for now).
There was a problem hiding this comment.
As it may change soon I think it's better not to give this precision.
|
|
||
| - **Data Dependencies**: Input data for a given task that depends on another unique task. Data dependencies formalize dependencies between tasks. | ||
|
|
||
| - **Expected Outputs**: Data that must be generated as output from a task. If a task submits new tasks then it can transfer responsibility for generating all or part of its outputs to the tasks it submits. |
There was a problem hiding this comment.
Above you are speaking about results, why not use this term here?
There was a problem hiding this comment.
I'm avoiding using the word "results" since we aim to use Blobs from now on. Maybe I could take out the other usage of this word to avoid confusion.
There was a problem hiding this comment.
Following the idea to avoid using the term "result" maybe we should avoid using "data dependencies" but "expected input ids" instead?
Co-authored-by: ngruelaneo <100275739+ngruelaneo@users.noreply.github.com>
Co-authored-by: ngruelaneo <100275739+ngruelaneo@users.noreply.github.com>
Co-authored-by: ngruelaneo <100275739+ngruelaneo@users.noreply.github.com>
Co-authored-by: ngruelaneo <100275739+ngruelaneo@users.noreply.github.com>
Co-authored-by: ngruelaneo <100275739+ngruelaneo@users.noreply.github.com>
Co-authored-by: ngruelaneo <100275739+ngruelaneo@users.noreply.github.com>
No description provided.