On Thu, 3 Jan 2019 at 17:43, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Thu, 3 Jan 2019 at 16:33, Dan Rue dan.rue@linaro.org wrote:
On Thu, Jan 03, 2019 at 01:31:06PM +0000, Milosz Wasilewski wrote:
Hi Dan, Thanks for great work
On Wed, 2 Jan 2019 at 22:51, Dan Rue dan.rue@linaro.org wrote:
To follow up on my original post which I guess didn't garner much attention, here's a working docker compose config which uses the latest production lava containers, and launches a single qemu worker.
https://github.com/danrue/lava.home.therub.org/tree/b17ed0f8a660f9a8c31f892d...
Running 'docker-compose up' then brings up a postgres container, a lava master container, and a dispatcher container. A few settings files are mounted into the master container, as well as devices and health-checks. The dispatcher itself must be run in privileged mode in order to use (at least) /dev/net/tun.
I tried this today and there seem to be some access/race issue with database. Here is the snippet from the log
database_1 | waiting for server to shut down....LOG: shutting down database_1 | LOG: database system is shut down server_1 | Starting PostgreSQL 9.6 database server: main. server_1 | done server_1 | server_1 | Applying migrations server_1 | Traceback (most recent call last): server_1 | File "/usr/lib/python3/dist-packages/django/db/backends/base/base.py", line 199, in ensure_connection server_1 | self.connect() server_1 | File "/usr/lib/python3/dist-packages/django/db/backends/base/base.py", line 171, in connect server_1 | self.connection = self.get_new_connection(conn_params) server_1 | File "/usr/lib/python3/dist-packages/django/db/backends/postgresql/base.py", line 176, in get_new_connection server_1 | connection = Database.connect(**conn_params) server_1 | File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 164, in connect server_1 | conn = _connect(dsn, connection_factory=connection_factory, async=async) server_1 | psycopg2.OperationalError: could not connect to server: Connection refused server_1 | Is the server running on host "database" (172.18.0.2) and accepting server_1 | TCP/IP connections on port 5432?
However when I later checked all tables were created.
It's a race that Remi fixed that already @ https://git.lavasoftware.org/lava/pkg/docker/commit/98fe3deecbdddfc03e99fdb8..., but the containers have not been republished yet. I updated https://github.com/danrue/lava.home.therub.org/tree/3792145057146d491413e71b... to use the fixed entrypoint.sh locally in the meantime.
Note that the compose file is using a docker volume for pgsql, which you'll have to remove if you want to re-test the first run.
I'll try it once I finish with other tasks.
I noticed one more small issue - the device-types and devices are not defined in the database. This can be easily fixed with adding initial fixture to the database.
I don't think fixtures are necessary (and could cause problems with upgrades containing database migrations themselves).
lava-server manage has the support to add device-types and devices to the database.
lavacli has device add support, via the XMLRPC API: https://staging.validation.linaro.org/api/help/#scheduler.devices.add
Similarly for device-types: https://staging.validation.linaro.org/api/help/#scheduler.devices.add - these calls (with the relevant authentication) will create device-types and devices in the database.
Once up, run something like the following to add an admin user: docker-compose exec server lava-server manage users add --staff --superuser --email dan.rue@linaro.org --passwd foo drue
Then, you may go into the admin interface to add the devices.
The only real gap that I can see is that the docker containers have the architecture hard coded in the container name. This should use a manifest[1] instead so that running docker on ARM "just works". A lot of work has been done to make architecture transparent when running docker (for the benefit of ARM users like us) - we should use it.
Next step - I spoke with Matt Hart about the idea of having lava be more ephemeral. If you don't actually need your historical runs, you could have lava re-configure itself every time on start-up, based on the contents of devices/ and health-checks/. I'm not sure the best way to do
what is the use case for this?
kernelci doesn't rely on any data being kept in lava. It's kind of a nice idea - if you can get away from keeping state in lava, it means you can deploy from scratch every time and so it makes trying arbitrary lava versions easy, not to mention easy upgrades and downgrades.
ok, got it. One potential issue is that all the files required to reproduce the test job are gone. So when lava code changes the same test job definition might produce different result. In some cases it's not a problem though.
milosz
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users