Set X31 to 5s as expected by the testsuite to fix currently failing:
It was recently increased to 15s in the related patch.
Related: osmo-hnbgw I24225cfc0addf326c239ec658a27b93b83a3e751
Config changes matching cnpool tests added in osmo-ttcn3-hacks, see
Keep a copy of the old config files named "-legacy", to not break the
'latest' tests, because osmo-hnbgw 'latest' does not yet support the new
Depends: osmo-ttcn3-hacks I027a059faed3f140f8801f84338956cd004043b5
Older commit disabled the talloc report checks but forgot to add the
same line to the with-pfcp/ variant, and as a result the sed command in
jenkins.sh won't work there.
Fix current jenkins test breakage:
Adjust HNBGW_Tests.cfg after changes to osmo-ttcn3-hacks in
"hnbgw: prepare cn pool: add multiple MSCs and SGSNs"
It was recently decided it's a good practice to always specify the role
and sctp-role for all ASPs configured in the VTY, since it's an
important configuration providing feedback on the network setup
Until recently, the asp-clnt-* ASPs, which have specific handling in osmo_sccp_simple_client_on_ss7_id(),
were being always forcedly set to sctp-role CLIENT by code in that
This prevented user of that API from explicitly configuring the ASP as
"sctp-role server" through the VTY as the option would be overwritten silently.
Now, the sctp-role from config is followed if the ASP is
defined/configured through the VTY (not dynamically created at the time
osmo_sccp_simple_client_on_ss7_id() is called).
Since the default for a VTY-specified ASP is to be in "sctp-role
server", the config files need to be updated to properly configure the
ASP to be in "sctp-role client", which is the desired mode here.
Same applies for "role", where the default is SG but it is actually used
as "ASP" here.
Depends: osmo-ttcn3-hacks.git Change-Id I4eb5b5f6b4b24df079b4c74e2a2e2ebb8769b0bd
As "docker kill" / "docker container kill" (alias) doesn't block until
the given container stops, make sure to always run "docker wait"
Try multiple subnet numbers until successfully creating a network. This
way we can run the same ttcn3 testsuite multiple times in parallel
without conflicts (e.g. once against latest, once against nightly). Also
we don't need to make sure each new testsuite has a unique subnet
I've considered also adjusting network_bridge_create, but that gets used
exclusively by osmo-ran/jenkins.sh, a script which we don't actually run
in jenkins. It seems that in this script it makes more sense to not get
a random subnet number.
The functionality is not in -latest yet so running osmo-hnbgw with this
configuration fails which in turn fails the test in jenkins instead of
just marking it unstable.
Same as done in BTS_Tests. This makes sure the files are always properly
updated even if something goes wrong (such as docker kill failing to
stop hnbgw because it exited earlier due to unsupported feature).
Other remotes are mirrors of gerrit one, which means there's some delay
between pushing some ref to the gerrit remote and having them available
in the mirrors.
Hence, it becomes annoying while developing and new stuff to test is
pushed. Let's simply use gerrit since it's the master remote.
Run HNBGW tests a second time with PFCP enabled. Just run all the same
tests again, no matter if they are related to PS RAB Assignment or not,
to also ensure no ill side effects from PFCP configuration.
Depends: I511e758807e0512c18f3f9e0a8c4699b9a3f5992 (osmo-ttcn3-hacks)