Scaling up virtual bts tests for the BTS test - how I hold it wrong?

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Pau Espin Pedrol pespin at sysmocom.de
Thu Jan 3 15:13:04 UTC 2019


Hi Holger,


>> 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
>    -subs:
>     times: 100000
>     pool:                          <- define IMSI/MSISDN pool
>       -name: Foo
>        imsi_start: XXXX
>        msisdn_start: XXXX
>        kind: draw_at_random
>        times: 10k
> hlr:
>    ...
> 
> 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[0].bts[all].type=osmo-bts-virtual --suite_override=hlr[0].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 
system.

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().

Something like
[suite.conf]
   bts:
   - times: 1

[mod-num-bts.cfg]
modifiers:
   bts:
   - 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.

Regards,
Pau

-- 
- 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 mailing list