In the future, some environments/products may come with a trx interface
pre-installed. Start work to easily disable launching it.
Change-Id: I556c3e2ba16753393c7e70800c533a18122daeaa
Otherwise osmo-bts stores the socket file in /tmp. If an earlier
instance doesn't finish cleanly, the file is left there and a new
instance will fail to start because it cannot create a new socket file
in the same place.
Change-Id: I5a1da23c45a4ac496fe765e0d78c52dae3e7808b
With this patch, the same errors are still happening.
This is not a solution, so drop this again.
This reverts commit 6c8d9497f2.
Change-Id: I324e965fdf40a369e1bcebfa4b32d0a3a7b86eb3
Processes created have the scope of the test, so we should store
everything in a per-suite_run/per-test directory, otherwise everything
is stored in the same trial run_dir directory and it's really messy.
Change-Id: I06be2dd21710e14c1337d13b1fe6c2f68f037957
We get sporadic clock skews when running osmo-bts-trx, causing the process to
end and the test to fail. Try to give some seconds for the osmo-trx process to
sort itself out, in the hope to avoid the clock skews.
Related: OS#2325
Change-Id: I82d29358498e7ad9fef28d409808168926e2f876
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
The "Affero" nature makes sense for the Osmocom network components like
BSC, SGSN, etc. as they are typically operated to provide a network
service.
For testing, this doesn't make so much sense as it is difficult to
imagine people creating a business out of offering to run test cases on
an end-to-end Osmocom GSM network. So let's drop the 'Affero' here.
All code is so far developed by sysmocom staff, so as Managing Director
of sysmocom I can effect such a license change unilaterally.
Change-Id: I8959c2d605854ffdc21cb29c0fe0e715685c4c05
To start an MGCPGW, we so far need the BTS address in advance (should get fixed
at some point, but so far we do).
The sysmoBTS has a fixed IP address configured. The osmo-bts-trx so far always
uses 127.0.0.1 (should also be fixed at some point). Both now return this
address with the remote_addr() function.
This also replaces a SysmoBts.remote_addr member variable (which is not
sufficient because it is only populated during configure()).
Change-Id: I7af9275914f34808cb60ae16b65ecd3688fd6b5b
A NITB is a BSC + MSC, and if a BTS talks to a NITB, it talks to the BSC part
of the NITB. Hence it makes more sense to name certain things 'bsc' instead of
'nitb', to prepare for a separate BSC process appearing soon.
Change-Id: I6a0343b9243b166d4053cc44f523543f1245d772
My current distribution ships a newer libcrypto and libssl which are not
ABI compatible with the ones generated by Jenkins. I had to copy those
libraries locally and use LD_LIBRARY_PATH to be able to run binaries
compiled coming from the jenkins slave. Without this patch I am not
able to run it because it is overwriting the previous variable.
Change-Id: Id9b16d13d343616cbf87b9da8a99e3fae48da6bd
Clearly separate the kinds of BTS hardware the GSM tester knows ('type') from
the NITB's bts/type config item ('osmobsc_bts_type' -- not 'osmonitb_...' to
stay in tune with future developments: it is the libbsc that needs this).
For BTS hardware kinds, use the full name of the binary for osmo driven models:
osmo-bts-sysmo, osmo-bts-trx, osmo-bts-octphy.
Change-Id: I1aa9b48e74013a93f9db1a34730f17717fb3b36c
I know that these commit messages aren't very good, but the code is not stable
yet, so I'm not bothering with details.
Change-Id: I2d5e5f4a5407725d71093cbd71ef97b271eb8197
Pau Espin
Neels Hofmeyr
Harald Welte
Neels Hofmeyr