1.1.2. Orchestrator Node

Orchestrator (Back-end) Orchestrator (Back-end) ML Model Metadata Node ML Model Metadata Node CO2 footprint CO2 footprint HW Constraints Node Carbontracker Node Carbontracker Node HW Constraints HW Constraints HW Resource HW Resource ML Model ML Model User input data User input data ML Model ML Model HW Resource HW Resource ML Metadata ML Metadata Baseline forOptimization Application-levelRequirements Node User input data User input data User input data User input data App Requirements App Requirements CO2 footprint CO2 footprint Front-end Front-end User input data User input data Output data Output data User User Model Provider Node ML Solution Provider ML Optimization HW Provider Node FPGA Selector... PIM Results

The Orchestrator Node within the SustainML Framework is the entity in charge of commanding and gathering the generated data by each of the Module Nodes as well as acting as the data-source for the Front-End Node.

The Orchestrator Node has three main resposibilities:

1.1.2.1. Manage nodes’ lifecycle

It is the application’s Lifecycle Manager meaning that it controls the lifecycle of the rest of the nodes by sending control commands and receiving the feedback status.

1.1.2.2. Monitor tasks

Each user task has an associated task_id. The Orchestrator Node is in charge of generating a unique task_id and keeping track of the status of every initiated task, which allows for serving multiple tasks at a time. The act of tracking a particular task, involves subscribing to all the intermediate data outputs from each of the Module Nodes as well as always monitoring the node statuses to be able to react, for instance, in case that a module node is taking too much to respond, or simply, that enters in and error state. Each of the task_ids along with the corresponding data, has a reserved storage within the orchestrator as it is explained next.

1.1.2.3. Host database

The Orchestrator Node is where all the data reside. It can be considered similar to a Database. All the data is indexed by the task_id. Each task_id is a pair of problem_id and iteration_id. Meanwhile a problem_id is generated per user problem defined, and an iteration_id is generated per interaction during the optimization of the problem_id defined problem. A problem_id, in turn, has a sorted vector of iteration_id where each element stores a single iteration for that problem. All the information is made available to the Front-end to be displayed so the user can receive online feedback on the status of each task.