Attention is currently required from: pespin.
1 comment:
Patchset:
What do you mean with duplicate here? Using the command twice creates no duplicate at all in the set, so it should be totally fine.
The same ARFCN value appearing in the hopping set configuration twice.
Why would you want to stop osmo-bsc from starting? because that command is set twice? that is really agressive and I see no necessity for that.
Because the current way we offer for configuring the hopping parameters is a bit complicated, IMO. It's so easy to make a mistake there, and then debugging why you're seeing unexpected BER on dedicated connections may take a while. This happened to me already.
If at all, print some warning to make the user notice that this one was already added, so that they can see and check if they had a typo, but that's all.
Who reads those warnings? They're printed in the beginning, and then quickly getting crowd out by lots of other logging. I oftentimes see deprecation messages in customers' logs, I guess because the operators simply do not notice them.
Furthermore it is creating problems with apply-config-file for no good reason, so let's avoid blocking reading config files which have commands being applied twice changing no state.
I am not really sure if blindly appending hopping ARFCNs is correct. Imagine an operator wants to configure a new set. I think the existing set must be cleaned first, otherwise you may end up having a mix of old and new ARFCNs.
To view, visit change 29551. To unsubscribe, or for help writing mail filters, visit settings.