Preservation of application state between invocations of the system

[RichardBruskiewich]

This issue is a spin-off from https://github.com/galaxy-genome-annotation/dockerized-gmod-deployment/issues/16, where it is mostly manifest.

Basic nature of issue: persistance of Tripal user/site specific state (e.g. user accounts, site content customized by the Dashboard, etc.) in between Tripal container sessions seems problematic. I'll investigate mechanisms which may alleviate the problem.

[hexylena]

You shouldn't need any changes for this?

In the current docker-compose.yml there is a line specifically stating that a volume is associated with it, if you mount that volume somewhere it should persist the data and re-use it between runs of the container.

Have you tried something like this?

       volumes:
-        - /var/lib/postgresql/data/
+        - ./tripal_db:/var/lib/postgresql/data/

[RichardBruskiewich]

There seems to be a strange problem that the "docker-compose up" will only successfully launch the Tripal service the first time it is run, creating the system (and its data) from scratch.

Executing "docker-compose down" then relaunching the service with "docker-compose up" results in the Tripal service exiting prematurely.

The docker-compose log files at the point of failure shows the following:

tripal_1         | Executing: PGPASSFILE=/tmp/drush_V7K13c psql -q --dbname=postgres --host=postgres --port=5432 --username=postgres  --no-align --field-separator='    ' --pset tuples_only=on --file /tmp/drush_P5MDH1
tripal_1         | Executing: PGPASSFILE=/tmp/drush_LLhMZz psql -q --dbname=postgres --host=postgres --port=5432 --username=postgres  --no-align --field-separator='    ' --pset tuples_only=on --file /tmp/drush_b9nTwo
tripal_1         | "authenticated user" already has the permission "view bio_data_1"           [ok]
                                    …bio_data_2 through 26 (omitted for brevity)
tripal_1         | "authenticated user" already has the permission "view bio_data_27"          [ok]
tripal_1         | Command dispatch complete                                               [notice]
tripal_1         |
tripal_1         | Installation is now complete. You may navigate to your new site. For more information on using Tripal please see the installation guide on tripal.info.
tripal_1         | Command dispatch complete                                               [notice]
**docker-tripal_tripal_1 exited with code 1**

As best as I can ascertain, even if one binds the various volumes in the docker-compose file to 'bind' or named volumes, the result is the same: Tripal crashes during restart the second time (when the system has already been initialized).

Noteworthy is that is doesn't crash if anonymous data volumes are used, but every invocation of "docker-compose up" creates a completely new set of (anonymous) docker volumes, which proliferate and fill up the host disk drive as /var/lib/docker/volumes. Moreover, these anonymous volumes do not reuse the data from previous container sessions.

[RichardBruskiewich]

The above error still seems to be a persistent issue. The restart of Tripal is not idempotent between docker-compose up/down cycles, whenever persistent data volumes are used (local bind or named volumes). The output is inadequate to diagnose the point of failure. I sense that I'd have to attempt a local docker image build with the core docker-tripal project to intercept the point of failure, but I was hoping that perhaps the error would be reproducible on your side, and you'd know where to look.

[hexylena]

Did these additional mount points affect it? Or not? Sorry, I have not had time to investigate this, I'm on holiday for the next three weeks, and I think @abretaud is out too.

[abretaud]

I'm still around this week, but I haven't found time to look into it, sorry... I'll try to have a look by the end of the week

[RichardBruskiewich]

Hi everyone,

First of all, I'll attempt a direct rebuild of the system here, with some diagnostic modifications to the start up scripts, to see if I can zero in on the problem.

Second, just to reiterate, I think we didn't see this problem previously because every docker-compose up operation recreated all the (anonymous) volumes of the system (stored in anonymous named subdirectories under /var/lib/docker/volumes, under Ubuntu). This meant that no data was persisted.

@erasche you substituted 'bind' volumes and yes, this ensured data persistence, but for the docker-tripal, there seems to be some kind of failure which happens only if the system data is already present (built in a previous container session).

Like I said, I'll systematically investigate this today.

Enjoy your holiday break. I'm sure we'll sort this out between the three of us sometime soon.

[abretaud]

Hi, So I've tested both tripal 2 and 3 images, with the latest docker-compose.yml available online, and I couldn't reproduce your problem. If you still have it, could you paste your docker-compose.yml here? To reassure you: the problem you get is not normal, I have ~20 tripal dockers running in production, I had to stop/restart them several times, and it worked well. As long as you mount a tripal html dir corresponding to the correct mounted chado data dir, everything should work fine. You might also get some problem when trying to instal tripal 2 modules in a tripal 3 instance.

[RichardBruskiewich]

The introduction of locally bound volumes plus some additional documentation on the perils of changing the Tripal/Drupal admin username after the Compose build of the system have substantially dealt with this issue.