Merge remote-tracking branch 'upstream/main'

.gitignore

@@ -36,3 +36,9 @@ venv/
 *.bkp
 *.bkp.*
 *bkp*
+
+# Build output
+/build/lib/
+
+# Auto-generated file
+/tuning/_version.py

architecture_records/001-trainer-controller-framework.md

@@ -126,4 +126,4 @@ Following is a high-level design diagram. Following are the touch-points to the
 - **Configuration**: The trainer controller configuration supplies the definition for triggers, rule, operations and metrics to orchestrate the enactment of a particular control policy. These details are split up and passed off to the respective modules by the trainer controller as shown in the figure.
 
 - **Events**: Events supply the state and arguments required for the metric handlers to perform metric computation at the events they are registered for. The framework callback lists out all event handlers with prefix `"on_"` and loads then as event handlers. Every metric declares one or more events from this list of valid handlers. These computed metric variables are stored in a global state of the trainer controller and independently picked up the operations which could potentially be triggered on an entirely different set of events. This decouples the control loop for metrics and operations. I.e. the metric could be computed on event A, while operation could be triggered on event B. The controller rules which use the metric variables from the trainer controller state are evaluated and based on the outcomes specified actions are performed.
-![High-Level Design Diagram: Trainer Controller Framework](arch.png)
+![High-Level Design Diagram: Trainer Controller Framework](imgs/001-arch.png)