Project

General

Profile

Actions

Bug #3369

closed

no automatic testing of Debian/Ubuntu packages

Added by laforge over 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
06/29/2018
Due date:
% Done:

100%

Spec Reference:

Description

We should have some automatic test job for the Debian/Ubuntu packages to ensure that the packaging is consistent. Tests should at the very minimum ensure:
  • that the included example config files can actually be parsed and the respective osmo-* programs can be started with them
  • that the included example configs are compatible, i.e. if all example configs are used, the resulting network is functional

If we include systemd service files, one could also check if the processes are properly started by them.


Related issues

Related to OsmoHLR - Bug #3368: osmo-hlr debian package is missing a mkdir for /var/lib/osmocomResolvedpespin06/28/2018

Actions
Related to OsmoSTP - Bug #3367: osmo-stp debian package is missing example configResolvedpespin06/28/2018

Actions
Related to OsmoMGW - Bug #3366: osmo-mgw debian package is missing example configResolvedpespin06/28/2018

Actions
Related to OsmoBTS - Bug #3364: osmo-bts(trx.. etc) debian packages should have some conflict to osmo-bts (old debian packages)Resolvedpespin06/28/2018

Actions
Related to OsmoTRX - Bug #3363: osmo-trx-uhd debian package is missing example config and systemd service fileResolvedpespin06/28/2018

Actions
Related to OsmoTRX - Bug #3362: osmo-bts-trx debian package is missing example configResolvedpespin06/28/2018

Actions
Related to Cellular Network Infrastructure - Bug #3176: osmocom debian packages are not install / upgrade testedResolvedosmith04/16/2018

Actions
Related to Cellular Network Infrastructure - Feature #4107: Start systemd services as non-root userStalledosmith07/15/2019

Actions
Related to Cellular Network Infrastructure - Bug #4108: osmo-ctrl2cgi, osmo-trap2cgi: missing default configsNew07/16/2019

Actions
Related to Cellular Network Infrastructure - Feature #4109: debian-repo-install-test: start a virtual MS and perform a LUNewosmith07/16/2019

Actions
Related to Cellular Network Infrastructure - Feature #4563: install test for centos packages (like the debian install test)Resolvedosmith05/25/2020

Actions
Actions #1

Updated by laforge over 5 years ago

  • Related to Bug #3368: osmo-hlr debian package is missing a mkdir for /var/lib/osmocom added
Actions #2

Updated by laforge over 5 years ago

  • Related to Bug #3367: osmo-stp debian package is missing example config added
Actions #3

Updated by laforge over 5 years ago

  • Related to Bug #3366: osmo-mgw debian package is missing example config added
Actions #4

Updated by laforge over 5 years ago

  • Related to Bug #3364: osmo-bts(trx.. etc) debian packages should have some conflict to osmo-bts (old debian packages) added
Actions #5

Updated by laforge over 5 years ago

  • Related to Bug #3363: osmo-trx-uhd debian package is missing example config and systemd service file added
Actions #6

Updated by laforge over 5 years ago

  • Related to Bug #3362: osmo-bts-trx debian package is missing example config added
Actions #7

Updated by laforge over 5 years ago

Ideally the resulting test (however it may look like) would be automatically executed every night after rebuilding the latest and nightly package feeds. I think it's sufficient (for now) to test on one distribution, i.e. Debian 9. It probably makes sense to start from a clean install each time, which could e.g. be achieved by debootstrap or (faster) a Dockerfile which uses a debian minimal install as base image/layer.

Actions #8

Updated by laforge over 5 years ago

  • Assignee changed from lynxis to osmith
Actions #9

Updated by osmith over 4 years ago

  • Status changed from New to In Progress
Actions #10

Updated by osmith over 4 years ago

  • % Done changed from 0 to 30

WIP branch: osmith/repo-install-test

I'm extending the existing osmocom-debian-install-test from #3176, which is already installing all (nightly, latest) Osmocom packages in a docker container to see if there are bugs at installation time.

So far I have added a new custom docker container for the test, which has systemd installed and is actually able to start systemd in docker. This allows starting Osmocom programs with the systemd services shipped in our binary packages. I've tried to start all osmo-* services at once and found a few conflicts/possible bugs:

  • osmo-ctrl2cgi (missing config: /etc/osmocom/ctrl2cgi.ini)
  • osmo-trap2cgi (missing config: /etc/osmocom/%N.ini; I'm not sure what %N is supposed to be here)
  • osmo-sgsn (port 2123 already used by osmo-ggsn)
  • osmo-pcu (expects missing /tmp/pcu_bts socket)
  • osmo-hnbgw (has IP 10.23.24.1 hardcoded in config)
  • osmo-bts-virtual (can't change cpu scheduling in docker (I'll fix/workaround that); unit_id is not matching osmo-bsc's config)
These services start up fine:
  • osmo-bsc
  • osmo-gbproxy
  • osmo-ggsn
  • osmo-gtphub
  • osmo-hlr
  • osmo-mgw
  • osmo-msc
  • osmo-pcap-server
  • osmo-pcap-client
  • osmo-sip-connector
  • osmo-stp

Furthermore I found that a few services are writing to /, the files /sms.db, /gtphub_restart_count and /gsn_restart have been created. Maybe it is worth adding a check for that as well? According to FHS, /var/lib/ is the right path to use.

that the included example configs are compatible, i.e. if all example configs are used, the resulting network is functional

laforge, what exactly do we want to test? So far I'm just starting the services, and I think this is good for a first approach. But if you like, we could also connect a virtual mobile with faketrx and check if location update works.

Actions #11

Updated by osmith over 4 years ago

  • Related to Bug #3176: osmocom debian packages are not install / upgrade tested added
Actions #12

Updated by laforge over 4 years ago

On Fri, Jul 12, 2019 at 01:11:37PM +0000, wrote:

laforge, what exactly do we want to test? So far I'm just starting the services, and I think this is good for a first approach. But if you like, we could also connect a virtual mobile with faketrx and check if location update works.

I agree that in a first check we should start all the services.
Ideally, as far as possible, we should start them as non-root user
(which may require changes to our systemd service files, etc. in the
individual git repos - but that is fine!). Starting them as non-root
will also means that any writes to unintended directories like '/'will
be discovered as they then would make the program start fail.

Starting everything up is a good first step. The second step, as you
noticed, could be to start a virtual MS and perform a LU. However, I'm
not sure we want to spend that much time on this right now. All the
non-application binary packages are tested (at least on Debian 9) as
part of our ttcn3 tests, where all dependencies execpt the final
"program under test" is installed from the package feed. How much time
do you think would be required to go as far as the "LU test?

Actions #13

Updated by osmith over 4 years ago

laforge wrote:

How much time do you think would be required to go as far as the "LU test?

Roughly two to three days (this estimation includes the work that is required to finish this issue up without the LU test).

Actions #14

Updated by osmith over 4 years ago

  • Related to Feature #4107: Start systemd services as non-root user added
Actions #15

Updated by osmith over 4 years ago

  • % Done changed from 30 to 50

laforge, with the time estimation above, do you think it is worth adding the LU test now?

All the non-application binary packages are tested (at least on Debian 9) as part of our ttcn3 tests, where all dependencies execpt the final "program under test" is installed from the package feed.

True. The purpose of that test would only be to make sure that all configurations work out of the box, as we are using different configs for the TTCN3 tests we might still end up with services that start up, but due to wrong default configs can't connect to the other Osmocom components. I think it would be a good addition, but I would understand if you said it is too time consuming to implement this.

Patches for starting the services (with only the known working services enabled):
https://gerrit.osmocom.org/q/topic:%22repo-install-test-systemd%22+(status:open%20OR%20status:merged)

Actions #16

Updated by osmith over 4 years ago

  • Related to Bug #4108: osmo-ctrl2cgi, osmo-trap2cgi: missing default configs added
Actions #17

Updated by osmith over 4 years ago

  • Related to Feature #4109: debian-repo-install-test: start a virtual MS and perform a LU added
Actions #18

Updated by osmith over 4 years ago

  • % Done changed from 50 to 90

I have created a separate issue for the LU test (#4109), with priority set to low. Please adjust as needed.

Regarding the failing services:
  • osmo-hnbgw: patch submitted to set the IP to 127.0.0.1
  • osmo-bts-virtual: patch submitted to adjust osmo-bsc's config to have the same unit id
  • osmo-pcu: the missing /tmp/pcu_bts socket gets created when osmo-bts-virtual starts up properly
  • osmo-sgsn: was actually conflicting with osmo-gtphub, patch to adjust the config submitted

With these changes, all services can start up properly, with the only exception being osmo-ctrl2cgi and osmo-trap2cgi. They don't seem to be widely used, so I have just opened an issue for them (#4108).

Actions #19

Updated by osmith over 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

All patches are merged.

Actions #20

Updated by osmith almost 4 years ago

  • Related to Feature #4563: install test for centos packages (like the debian install test) added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)