migrate jenkins master to machine with lots of HDD storage
With the increaes of test jobs, the storage requirements of our jenkins master (for the build artefacts archive) are exploding. Right now its 528GB. Most of it is the BTS test jobs, and interestingly not their pcap files anymore but the merged TTCN3 test logs.
97G TTCN3-centos-bts-test 36G TTCN3-centos-bts-test-latest 98G ttcn3-bts-test 78G ttcn3-bts-test-latest
Those text files would nicely compress (one example file from > 80MB to 2.6 MB), but jenkins seems to neither decompress on the fly, nor send the correct mime type to the browser to enable the browser to show uncompressed text.
So rather than patching jenkins or coming up with other non-standard methods that affect usability, the best is to move to larger storage.
Unfortunately adding disks to Hetzner servers is disproportionally expensive. For adding two 4TB disks to a server we can actually just as well get another dedicated server with those disks in it.
So my plan is to actually rent another dedicated server with 2x 4TB RAID-1 storage and run nothing but the jenkins master there. The build slaves would still be NVMe SSD based, so the slow storage of the master shouldn't really matter.
library/PCUIF_Types: get rid of version 9 compatibility glue
library/PCUIF_Types: use PADDING attribute for 'PCUIF_Message'
PCUIFv9 compatibility has been dropped in , so now we can tell
TITAN's RAW codec what kind of padding to expect in received
messages and to append to encoded messages. This eliminates
thousands of warnings about unhandled tail octets.
Related:  Ia9f366ca1fdad700a90ca3367e43523f7bac39a1
BTS_Tests: do not connect to PCUIF socket if not used
The PCUIF connection involves a lot of frequent messages, such as
the TIME.ind and since recently DATA.ind with len=0. As a result,
the test suite logs are getting unreadable due to lots of coding
warnings and port queueing notifications.
This change is aimed to improve the situation a bit, by establishing
the PCUIF connection only for those test cases which actually use it.
- TC_pcu_socket_verify_info_ind becomes reliable, because the
PCUIF establishment is done after the RSL bootstrapping;
- TC_pcu_socket_connect_multi starts to fail, because it used
to pass due to timeout, since not all messages are handled
in the 'alt' statement.
... and interestingly not their pcap files anymore but the merged TTCN3 test logs.
I think we can also reduce the size of logs by eliminating tons of PCUIF enc/dec messages, please see:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23461 library/PCUIF_Types: use PADDING attribute for 'PCUIF_Message'
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23465 BTS_Tests: do not connect to PCUIF socket if not used