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.deHi 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