This commit fixes combination of resources containing lists.
For lists containing complex types, it has been decided to handle them
as sorted list, where position in list matters. In this case, combine is
called recursively for each element in dest and src sharing position in
the list, and assumes that if one list is shorter than the other, then
it has to be combined against empty set for that tye.
For instance this is useful when defining trx_list properties, where a
BTS can have a different amount of TRX but we may be interested in
restricting the first TRX and don't care about extra TRX.
For lists containing simple types (eg. integers or strings), we just want
to merge both lists and we only need to check if the value is already there,
ie. handle them as unsortered sets. This case won't work if we call combine
for each element of the list because for a simple case it will just end up
checking if a[i] == b[i].
This kind of operation for simple types is needed in later commits where
cipher attribute is introduced. Without this patch, having following 2
scenarios and trying them to use together "-s foosuite:cipher-a50+ciphera51"
will fail:
cipher_a50.conf:
bts:
- ciphers:
- 'a5 0'
cipher_a51.conf
bts:
- ciphers:
- 'a5 1'
ValueError: cannot combine dicts, conflicting items (values 'a5 0' and 'a5 1')
Change-Id: Ib7a38f10eb9de338a77bf1fa3afceb9df1532015
As suite.conf and scenarios need to match 1-to-1 in lists, it's important to
extend the dictionaries by replicating the objects with a 'times' values
higher than 1 in order to match the objects correctly.
Since dictionanries are expanded at combine time, there's no need to
expand them during reserve() time because they are already expanded.
As a result, this commit reworks the kind of schema applied in each
place (and takes the change to start validating scenario files, which
were neglected previously).
Two unit tests are added as a show case. Unfortunately output showing
scenario dictionaries needs to be ignored while verifying because it was
encountered that different versions of python print dictionary elements
in different order.
Change-Id: I25eb639c7e3cf3b4c67a205422808bffbdd791e6
In the following suite.conf, position matters when matching against scenarios:
[suite.conf]
resources:
bts:
- type: sysmo
times: 2
- type: osmo-bts-trx
times: 1
[scenario]
resources:
bts:
-
- ip_addr: 1.2.3.4
In this case, for instance, we make it clear that we want the second
sysmo bts which has IP 1.2.3.4. With old behaviour, the replicated sysmo
would have been created at the end (3rd position), and the ip_addr would
match against the osmo-bts-trx BTS.
Change-Id: Id78e2326db964d5efb6648854b57d8addce4deb0
We may want to support running a device which runs its own TRX
(osmo-trx or different implementation). Furthermore, this TRX may be
available in some specific hwardare rather than on the main unit.
This makes it easy to configure OsmoBtsTrx to launch it's own
osmo-trx or not. In case it is launched, all IPs are configured correctly
to ensure connection can be established.
Before this commit, osmo-trx was binding to 127.0.0.1. Now we can
support multiple osmo-trx being launched on the main unit.
Change-Id: I825ed1fc0c3fe75d196db90c1508283fbd04acf8
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
Add -c cmdline option to do the same as / in addition to the
OSMO_GSM_TESTER_CONF var, because setting the var is cumbersome in daily
development.
Change-Id: I4c3b482f31f638047ab3f3d785d294b28d244b80
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
Tweak test expectations to include the new debug logging.
Go through the paths in alphabetical order to get deterministic logging output,
so the test expectations always match.
Change-Id: I11a905b2467cda691d9ccea30ae436bac96476c9
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
The original osmo-gsm-tester was an internal development at sysmocom, mostly by
D. Laszlo Sitzer <dlsitzer@sysmocom.de>, of which this public osmo-gsm-tester
is a refactoring / rewrite.
This imports an early state of the refactoring and is not functional yet. Bits
from the earlier osmo-gsm-tester will be added as needed. The earlier commit
history is not imported.
Pau Espin
Neels Hofmeyr
Harald Welte
Neels Hofmeyr