It's always been the default anyway, so no need to explicitly state it.
Furthermore, recently (osmobsc 167cb828665b91ed7d28007abd4a1862ebbb78c9)
force-combined-si was enabled by default for nanoBTS due to issues with
some MS not registering when it's not enabled, so let's osmo-bsc decide
were should it be enabled.
Related: OS#3063
Change-Id: I97b10406a4a0048c66a47aa7d32a113f0c0366d1
VTY cmd "logging level all" is deprecated in favour of "logging level
set-all", but the required behaviour in this case is "logging level
set-all".
Change-Id: Ice54fca6be86f05a02ce4ae783e6e42e6958b95d
Before this commit, only max_power_red was specified and it could only
be used as a defaults and could not be set per object. Together with
nominal_power, it can be useful to be able to set them to different
values for different objects, as for example different osmo-bts-trx
objects can require different values.
Change-Id: I472742e98052cc39686d38c945be76d7f50eeebd
As described in https://osmocom.org/issues/2380 and related gerrit
patch https://gerrit.osmocom.org/#/c/3306 the config files currently
contain timers with a 'zero' value, leading to issues.
The config file templates used in osmo-gsm-tester suffer actually
from exactly the same issue: They basically contain values that were
written back to the file based on the default initialization in libbsc,
which unfortunately was zero in some cases.
Let's remove those values, they are the (bad) default anyway.
libbsc patches in the pipeline will introduce reasonable defaults
and forbid the use of zero for timers.
Change-Id: I8cde29a597a17c2659b3b87268be4b12975f4bef
As defined in [1], the different related actors are implemented in this
commit: ESME and SMSC.
SMSC: In Osmocom, the SMSC is currently implemented inside the NITB or
the MSC. A new Smsc abstract class is created to shared code between the
NITB and the MSC, and also makes it easier for later when the SMSC is
splitted. ESMEs can be dynamically added to its configuration in a
similar way to how the BTSs are added.
ESME: A new class Esme is created which can be used by tests to control
an ESME to interact with the SMSC. The ESME functionalities are
implemented using python-smpplib. Required version of this library is at
least 43cc6f819ec76b2c0a9d36d1d439308634716227, which contains support
for python 3 and some required features to poll the socket.
This commit already contains a few tests which checks different
features and tests the API. Extending tested features or scenarios can be
later done quite easily.
The tests are not enabled by default right now, because there are several
of them in a suite and the ip_address resources are not freed after every
tests which ends up in the suite failing due to missing reserved
resources. All the tests run alone work though. When the issue is fixed
they can then be added to the default list of tests to be run.
[1] http://opensmpp.org/specs/SMPP_v3_4_Issue1_2.pdf
Change-Id: I14ca3cb009d6d646a449ca99b0200da12085c0da
With the recent fix of the junit report related issues, another issue arose:
the 'with log.Origin' was changed to disallow __enter__ing an object twice to
fix problems, now still code would fail because it tries to do 'with' on the
same object twice. The only reason is to ensure that logging is associated with
a given object. Instead of complicating even more, implement differently.
Refactor logging to simplify use: drop the 'with Origin' style completely, and
instead use the python stack to determine which objects are created by which,
and which object to associate a log statement with.
The new way: we rely on the convention that each class instance has a local
'self' referencing the object instance. If we need to find an origin as a new
object's parent, or to associate a log message with, we traverse each stack
frame, fetching the first local 'self' object that is a log.Origin class
instance.
How to use:
Simply call log.log() anywhere, and it finds an Origin object to log for, from
the stack. Alternatively call self.log() for any Origin() object to skip the
lookup.
Create classes as child class of log.Origin and make sure to call
super().__init__(category, name). This constructor will magically find a parent
Origin on the stack.
When an exception happens, we first escalate the exception up through call
scopes to where ever it is handled by log.log_exn(). This then finds an Origin
object in the traceback's stack frames, no need to nest in 'with' scopes.
Hence the 'with log.Origin' now "happens implicitly", we can write pure natural
python code, no more hassles with scope ordering.
Furthermore, any frame can place additional logging information in a frame by
calling log.ctx(). This is automatically inserted in the ancestry associated
with a log statement / exception.
Change-Id: I5f9b53150f2bb6fa9d63ce27f0806f0ca6a45e90
I would like to use the IP addresses also for OsmoBSC processes, so it is more
than clear now that 'nitb_iface' was the wrong naming choice.
The only distinction we may need in the future is public versus loopback
interface. To add that, we may add a trait to the 'ip_address' resource
like:
ip_address:
- addr: 10.42.42.1
type: public
- addr: 127.0.0.1
type: loopback
This way we can substitute public vs loopback addresses flexibly (e.g. using
scenarios).
Change-Id: I3ad583ae7a33f7a7bb56fe78a125f73c56a0e860
Pau Espin
Harald Welte
Neels Hofmeyr
Neels Hofmeyr