Possible 5G band restart regression in v2 beta about tmo-monitor HOT 2 CLOSED

Thanks for reporting, @delikat
I agree that the reboot flags are confusing, particularly since there's not really parity between the .env configuration and the cli flags.

@AndrewPardoe was nice enough to contribute the .env functionality and added the concept of breaking down the different triggers for a reboot. When testing for regressions this introduced, I took some notes that align with your report.

I believe much of the reboot behavior can be implicit - it feels like boilerplate to me to specify the reboot on bands if you're passing a list of band preferences. Same thing with passing an eNB ID preference.

I think it's helpful to summarize the list of reboot triggers in --print-config for debugging purposes.

The one thing I want to be easy is for any defaults to be overridden - the script is set to ping by default and to check for n41 by default.

A user passing their own 5G band preference or using --skip-5g-bands will ensure that the default does not get in the way.

Likewise a user can use --skip-ping if they don't want to reboot on ping.

What gets a little confusing semantically is if a user wants to check the latency with a ping and check the connected band for the purposes of logging it. Then a ping is still being performed and the connected bands are inspected, but they're not going to trigger a reboot.

I'd like to improve the usability of this while keeping things predictable, clear, and not overly verbose. I do think it's important to ensure that any configuration that is possible with the .env is possible with cli flags as well. You shouldn't have to create a .env file to ensure that you can reboot when the bands don't match.

from tmo-monitor.

@delikat, would you mind double-checking the logic in my PR #40?

from tmo-monitor.