> On 3. Jan 2019, at 15:13, Pau Espin Pedrol <[email protected]> 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
