4 Jan
2019
4 Jan
'19
3:36 a.m.
On 3. Jan 2019, at 15:13, Pau Espin Pedrol
<pespin(a)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. 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