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://firstname.lastname@example.org/.Holger Freyther holger at freyther.de
> On 3. Jan 2019, at 15:13, Pau Espin Pedrol <pespin at sysmocom.de> wrote: > Hi! let me spin this into a new thread. >> 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. SCNR. This sounds too much like "just write more code". ;) > 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 The number of "objects" is secondary. Let's say 40k subscribers, 256 BSCs, 512 BTS. The numbers are constant but there are many ways a network can be organized. And many present a nice problem/failure potential for our software stack. But what I want to stretch here. The topology does not matter to the success criteria (99% of subs manage to do X within Y units of time) or execution of the test (start mobiles and ask them to do stuff). If the topology does not matter, why would I want to change the test code? I want the suite to give me a configured network and then use the functional identities (e.g. connect to the SMPP interfaces, etc). If it is in a suite.conf, topology.conf or a RPC call is secondary to me. Does this change anything for you? holger