importing lrc with multiple cpu measurements fails

[olichtne]

https://github.com/LNST-project/lrc-file/blob/main/lrc_file/LrcFile.py#L86 assumes that the lrc file contains EXACTLY two cpu measurements. If there's only one, or if there's more than one (e.g. for OvSDPDKPvPRecipe there's 3) the LrcFile load crashes with an exception.

This will likely need a slightly larger refactoring and thought to put into how this is implemented as this cascades into other parts of the implementation.

[olichtne]

fyi @Kuba314

[Kuba314]

This choice of only 2 machines is influenced by the fact that we distinguish between a generator and a receiver machine. There has to be a way to distinguish the machines between each other in the .lrc files.

[olichtne]

we distinguish between a generator and a receiver machine

no, that's a misunderstanding from implementation specifics for some of our use cases. For CPU measurements, there is no concept of a generator or a receiver, there's only the Host that is being measured. The measurement does have its configuration which contains the information about which host is being measured and that's it.

For some of our internal use cases we've re-named some of the metrics in some places to map it a bit closer to the reality of what we're measuring, but this doesn't represent the real generalization or design behind this.

---

On a related note, this issue is not only about the fact that sometimes we may have 3 machines which we measure instead of 2. A recipe may have multiple smaller "tests" in it... for example in our ENRT package, the tests support looping over multiple sub configurations in a single test run. At the moment we don't use this feature internally, however this is an intended feature that can save significant amounts of test time that is spent on configuring-deconfiguring loops for similar tests.

In a case where we would use this feature even for recipes where we measure only the generator-receiver host pair, we'd still end up in a situation where filter(_is_cpu_measurement_result, lnst_run.results) would return N*2 cpu measurement results based on how many sub configuration loops we did.

---

This is the main reason why i mention that this will most likely require a larger refactoring as this assumption that we've made a long time ago for how to implement the LrcFile class cascades into many other places and it's an incorrect assumption.