feat(baremetal_validator): Add Validator for Process, Container Metrics

[KaiyiLiu1234]

This commit includes validation setups for Process and Container RAPL related Baremetal power metrics (node, process, container).

[github-actions]

🤖 SeineSailor

Here's a concise summary of the pull request changes:

Summary: This pull request introduces a baremetal validator for process and container RAPL-related power metrics, adding a new Bash script and several Python classes for stress testing. Key modifications include:

• New baremetal_validator script and Python classes (ProcessOutput, ContainerOutput, StresserError, Local, Process, and Container) for process and container stress testing.
• Introduction of new named tuples (BMValidator, Local, LocalProcess, LocalContainer, LocalPrometheus) for configuration data.
• Changes to the validate_acpi command to accept a duration argument and addition of a new regression command to the bm_validator group.
• Updates to the bload function to parse and initialize new fields from the YAML configuration file, with an updated configuration file format for baremetal validations.

Impact: These changes may affect the external interface and behavior of the code, particularly in the areas of stress testing and configuration data handling.

Observations/Suggestions:

• It would be beneficial to include unit tests for the new Python classes and Bash script to ensure their correctness and robustness.
• Consider adding documentation for the new regression command and its usage.
• The updated configuration file format may require changes to existing integrations or scripts that rely on the old format; ensure that these changes are properly communicated and addressed.

Overall, this pull request introduces significant new functionality for baremetal validations, but it's essential to thoroughly review and test these changes to ensure they do not introduce unintended consequences or break existing functionality.

[vprashar2929]

Couldn't we modify the existing stressor script instead of adding new ones?

[KaiyiLiu1234]

I did not want to modify the other scripts because it might break the metal ci. I think this script is the best to replace the other stressor scripts (as it enables a custom load curve). A future PR should be made for modifying validator to have just one goto stressor script.

[vprashar2929]

Why do we need to mount the directory? Also how are you planning to deploy Kepler on BM?

[KaiyiLiu1234]

Currently, kepler is deployed with docker compose for simplicity. however, this should still work the same even in a kubernetes environment. The mount directory is specifically to get the start and end times of the stressor script as a log file from the container. In a non container, the log file will be saved at the mount directory.

[vprashar2929]

Shouldn't we target a single environment for now and focus on expanding it further? Currently, we use docker compose for our development and validations. Let's stick with that for now and afterwards add support for k8s
Wdyt?

[vprashar2929]

What is the difference in the load curve between the process and the container?

[KaiyiLiu1234]

No difference. the logic is the same

[vprashar2929]

Then why we require separate configs for both?

[vprashar2929]

AFAIK we do something similar in our existing validator source by checking the start and end time of the stressor.sh script. I think we can do similar in this case as well instead of computing start and end time in the bash script itself

[KaiyiLiu1234]

The reason this is necessary is primarily for container validation and in future if we attempt pods (which should fall under container still anyway). Container setup requires an image installation (in this case, fedora and stressng need to be installed). If we get start and end time outside we will include the time for installing which will skew the results. The easiest solution I can think of was to actually compute it in the bash script so we do not include the installation time.

[vprashar2929]

Why can't we add a new load curve in the existing stressor and not make it part of the config as it overcomplicated the config part How's this different from what default load curve gives us?

[KaiyiLiu1234]

@vprashar2929 Since we are now refocusing on baremetal validation again, I will create new PRs breaking down this problem into smaller pieces for you to review. When that is complete, I will close this PR.

[vprashar2929]

@KaiyiLiu1234 Can you take a look at this? I believe this somewhat tries to achieve what we want from BM validations. Also please give it a go as well

[KaiyiLiu1234]

Sure I can take a look. We should probably organize tasks and merge the work between our PRs (I have no issue with directly merging your work and then adding what I did here on to yours - for container validation). In the meantime, I am going to just see if i can get some results asap from the metal ci.