Scaling up virtual bts tests for the BTS test - how I hold it wrong?
Pau Espin Pedrol
pespin at sysmocom.de
Thu Jan 3 15:13:04 UTC 2019
>> I'd like to be able to specifcy pools of objects in resources.conf so we don't need to add 1 line per object there. In the case of IP addresses, specifying a subnet range and let osmo-gsm-tester to expand that into a set of objects at runtime.
> +1. Do you have a timeline or open issue for it? Besides the IP pool I have needs for a combined IMSI/MSISDN pool
No timeline since I could workaround that myself so far by adding new IP
addresses manually. I tend to implement this kind of new features only
once I find I am really blocked or constrained by previous system when
trying to add new kind of tests (or more complex ones).
> There are two parts to this. The first is convenience API but to me the more important is topology. I would like to build the network based on the suite.conf and in the python code. As a first proposal (but we require a lot more thinking) what about something like:
> hlr: <- define a HLR. Multiple might be possible
> times: 100000
> pool: <- define IMSI/MSISDN pool
> -name: Foo
> imsi_start: XXXX
> msisdn_start: XXXX
> kind: draw_at_random
> times: 10k
> msc: <- MSCs connecting to it? High level or scope to HLR?
> type: nitb
> bsc: <- BSCs connecting to (void if NITB is used)
> times: 5
> -bts: <- BTSs
> type: <- ...
> virtual_mobiles: <- borrowing from the HLRs?
> What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable.
> One benefit is that the same test would work for both NITB and BSC/MSC.
TBH I don't like the idea of making the suite/scenario yml file
structure a lot more complex, I think current status is quite complex
and makes it already difficult to gasp how to put everything together.
The kind of stuff that you intend to do here can already be done far
more easily by using (or extending) the python test API. That's mostly
what the test does anyway: Setting up a specific topology with a
pre-allocated sub-set of objects, and then do some actions on that.
If you require several similar tests but with different number of
objects, you can abstract that by using the "lib" feature of a suite.
See for instance osmo-gsm-tester.git/suites/gprs/lib/testlib.py and its
users in osmo-gsm-tester.git/suites/gprs/lib/iperf3*.py
> I will give it a try. Please be aware that ARFCNs do not uniquely identify a band.
Yes, that's why in osmo-gsm-tester initial work around this topic
expects an arfcn to be actually a dictionary with ARFCN+BAND iirc.
>>> * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change).
>> Unfortunately these kind of capacities are so far fixed by the suite.conf. If you want to do tests with different numbers, you can manually change the "times" attribute in there, or put a big number and only use a subset of them when running the test in the suite.
> I am thinking of a xpath like command line parameter
> --suite_override=hlr.bts[all].type=osmo-bts-virtual --suite_override=hlr.bts.times=100
This kind of feature is similar to what scenarios provide already. The
issue is still though that in order to sanely combine and override yml
cfg files (lists, tuples, dictionaries, etc.) we require some
restrictions in order to make it "sane" and usable for most cases.
For instance right now we handle lists of "non-complex" attributes
(integers, strings, etc.) as sets when combining them, but we expect
lists of dictionaries to be the same size when merging them to have
meaningful result (so order of items in list is important when combining
or overwriting them).
Lists of objects are expanded before merging suites and scenarios, so
the "times" attribute is removed and item put in place in the list
before combine() and override() operations are done.
You may want to look at git history to understand reasons behind current
Maybe one could use scenario modifiers to change the amount of objects
from the suite.conf, that's something to explore, but I'd need to invest
some time testing and reading the code too. IIRC summary is that regular
suite.conf + scenarios are merged using combine(), while scenario
modifiers are merged using override().
- times: 1
- times: 2
I think to that in order to override() you also need same list size, due
to sanity checks. We could perhaps add a new "section" in scenarios
which overpasses these checks, let's call it "appends" or whatever,
which let's you add new requires resources to the suite.
These are my 5cents, not an ultimate answer but just some advises and ideas.
- Pau Espin Pedrol <pespin at sysmocom.de> http://www.sysmocom.de/
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
More information about the baseband-devel