You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When testing nanorc, one should generate 2 configurations, create a top_level.json and run the RC with it, because some problems only appear when running with 2 subsystem configurations (we run with this at np04: wibs and daq).
The text was updated successfully, but these errors were encountered:
I agree with the sentiment of this Issue completely. However, it would be helpful to understand a few details before we implement anything.
what was the problem that this integration test would have caught? (It would be helpful to know what that was so that we can be sure to address it in the test.)
do you have a suggestion for what to use for the second configuration? At the moment, I only know of WIBs as a possible source of that second config. Are there other options?
I think in this case, we could have caught that subsystem can't be booted in parallel, and need to be booted sequentially, due to a rich error. The change that introduced this "feature" was the FSM. This morning I also realised that even specifying an order for subsystem wouldn't do.
For the second configuration, a duplicate of DAQ would work, or listrev. However, the tricky thing here is it needs some manual changes in the boot.json, otherwise one gets port clashes (and they cannot be sorted by partition-number, at least as it is now).
When testing nanorc, one should generate 2 configurations, create a
top_level.json
and run the RC with it, because some problems only appear when running with 2 subsystem configurations (we run with this at np04: wibs and daq).The text was updated successfully, but these errors were encountered: