Project

General

Profile

Bug #3369

no automatic testing of Debian/Ubuntu packages

Added by laforge about 1 year ago. Updated about 5 hours ago.

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

50%

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/osmocomResolved06/28/2018

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

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

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

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

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

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

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

History

#1 Updated by laforge about 1 year ago

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

#2 Updated by laforge about 1 year ago

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

#3 Updated by laforge about 1 year ago

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

#4 Updated by laforge about 1 year ago

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

#5 Updated by laforge about 1 year ago

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

#6 Updated by laforge about 1 year ago

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

#7 Updated by laforge about 1 year 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.

#8 Updated by laforge 10 months ago

  • Assignee changed from lynxis to osmith

#9 Updated by osmith 5 days ago

  • Status changed from New to In Progress

#10 Updated by osmith 4 days 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.

#11 Updated by osmith 4 days ago

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

#12 Updated by laforge 3 days 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?

#13 Updated by osmith 1 day 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).

#14 Updated by osmith 1 day ago

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

#15 Updated by osmith about 5 hours 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)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)