Project

General

Profile

Feature #2270

add abstract API to picking which "core" network setup (NITB or MSC+BSC) to use by scenario

Added by neels 5 months ago. Updated about 1 month ago.

Status:
Rejected
Priority:
Low
Assignee:
osmo-gsm-tester
Target version:
-
Start date:
05/17/2017
Due date:
% Done:

0%

Spec Reference:

Description

After #2269, we have API to launch an OsmoNITB, and we have API to launch an OsmoBSC + OsmoMSC.

Consider this though: it would make sense to run the same SMS, voice etc. tests independently from whether an OsmoBSC+MSC or OsmoNITB is used.
For the resources like BTS and modems, we have the scenarios that allow picking various hardware for the same test runs.
But for the core network software launched, this is so far still explicit, for the very reason that a test should be able to start/stop/configure CN components in arbitrarily complex sequences.

It would be good to have the same powerful selection mechanism for the core network components, i.e. have an abstract API that can operate on both an OsmoNITB or an OsmoBSC + OsmoMSC "backend".
More specific tests should still be able to launch individual processes (have the choice to launch an OsmoBSC directly), but tests could choose to use an "abstract" core network that is then exchangeable between test run invocations using scenario configurations, without the need to write each test twice (once for NITB and once for MSC + BSC).


Related issues

Related to OsmoGSMTester - Bug #2307: osmo-gsm-tester: Proper object-oriented structure to handle different objects New 05/30/2017

History

#1 Updated by neels 5 months ago

  • Priority changed from Normal to Low

possibly we'll just drop the NITB style, in which case we don't need to implement a core network style selection, really.

#2 Updated by neels 5 months ago

  • Parent task deleted (#2267)

#3 Updated by neels 5 months ago

  • Subject changed from allow picking which "core" network setup to use by scenario to add abstract API to picking which "core" network setup (NITB or MSC+BSC) to use by scenario

#4 Updated by neels 5 months ago

  • Related to Bug #2307: osmo-gsm-tester: Proper object-oriented structure to handle different objects added

#5 Updated by neels about 1 month ago

  • Status changed from New to Rejected

doesn't look like we'll do this. We're going on fine with separate test scripts for the two cases; so far the NITB ones have no prefix, while the AoIP ones are prefixed aoip_. That naming may change to give mode weight to the AoIP tests and phasing out the nitb tests, other than that we're not likely to spend time on this.

Also available in: Atom PDF