All committers have signed the CLA.

This doesn't seem to work, as the snappea database is created while the Docker image is created.

My question would be: what is the use-case where /tmp/ is not available, but you are using the prebuilt Docker-image?

In my case, /tmp is not mounted by default on our Kubernetes in our OpenShift cluster. Mounting it would throw an error, as the database is not initialized, as that was done prior when the image was built. Moving the migration step to the run command, would at least cover the error, but allowing modifying the location would help end-users too.

are you saying /tmp is not mounted in the sense that it is not available at all (from within the docker image)?

in circumstances where /tmp is not writable at all, you'd probably also want to change the variable below. which makes me think that, in the context of Docker, pointing at "a temp dir" using an environment variable and using that information twice is then the better way forward than exposing 2 new enviroment variables for the docker config (since you'd always change them in tandem)

SNAPPEA = {
    ...
    "WAKEUP_CALLS_DIR": "/tmp/snappea.wakeup",

Maybe to add some other angle to this:

RUN ["bugsink-manage", "migrate", "snappea", "--database=snappea"]

Why is this run during the docker build?

It backes the sqlite file into the image with a given user and by that makes it impossible to switch the user the process is running as via security context (without creating a new image).

I built this branch and gave it a try in my Openshift: it makes Bugsink work without any quirks, given that I set DATABASE_PATH and SNAPPEA_DATABASE_PATH to point to a persistent volume.

RUN ["bugsink-manage", "migrate", "snappea", "--database=snappea"]

Why is this run during the docker build?

The thinking at the time was: this can run at build-time, because the information there is entirely ephemeral between restarts, and at some level it's prettier to not do this for each server start (philosophically: why would you? practically: it's faster)

Also: in principle it's possible to allow for "special commands" to take care of this, but I'd prefer my Docker image to take that out of the server-start; but pushing a requirement like that onto my users is against the design principles of "very simple to run".

It backes the sqlite file into the image with a given user and by that makes it impossible to switch the user the process is running as via security context (without creating a new image).

could you tell me a bit more (or point me to literature) about such setups? It seems I have something to learn here.

Once I've understood the problem-space at bit better, I will likely merg the code that moves the snappea migration to the place where the real migrations are already running.

@mephinet the fact that the PR "just works" for you, despite the fact that it currently does not provide for a way to set WAKEUP_CALLS_DIR (which is also under tmp somewhere) makes me believe that, to make Bugsink work under OpenShift, all we need is to push the snappea migrations to the on-start moment.

On the other hand, if /tmp must be configurable, I'd prefer to make both snappea-related paths which currently default to /tmp/something configurable using a single variable.

But before that, I'd like to know which one it is... configuration options are easy to add, but annoying to deprecate

I just checked again and did a few tests in my Openshift: the issue is not that /tmp is "unavailable", as the first comment states. The issue is that all files in the image are read-only in this locked-down environment. This includes all users and all directories, so it also includes user bugsink and directory /tmp. As I like to remind myself, Openshift is just Linux:

$ id
uid=1001280000(1001280000) gid=0(root) groups=0(root),1001280000
$ ls -l /tmp/snappea.sqlite3
-rw-r--r--. 1 bugsink bugsink 28672 Oct  9 22:56 /tmp/snappea.sqlite3

The current user is (in my case, this ID is generated once for each namespace) 1001280000 and group root. So any file that is not writable to this user or this group cannot be written to:

$ echo foo > /tmp/snappea.sqlite3
bash: /tmp/snappea.sqlite3: Permission denied

But it's important to remember: the /tmp dir behaves just as with any other unix system, the directory itself is not the problem:

$ echo foo > /tmp/any-other-file
(no error here)

That's why there is no issue with the WAKEUP_CALLS_DIR directory. It's just the existing file that is owned by a different user, that causes the issue here.

I think that @diamondo25 's solution of making the directory configurable and initializing it on startup time is a valid one. If we ware talking about a software that primarily targets Openshift, I would now start to argue that there are better ways to solve this, maybe initContainers and whatnot - but that's not the point here. We just want to make sure that it is possible, with the correct configuration, to use Bugsink in Openshift.

TL;DR: LGTM. https://www.bugsink.com/docs/docker-install/ would probably need another paragraph to document that in locked down environments, this new environment variable needs to be set to point to a volume writable by the user of the container.

I'm going to be what will presumably be perceived as extremely pigheaded to take this in as tiny steps as possible.

AFAICT, from the discussions above, the "part that matters" is that the bugsink user isn't the one doing the snappea migration. So we'll do that on-start, as per @diamondo25's work, now migrated to #264

I still believe that if the other half is needed, it should be done as a single setting that controls all snappea-related paths. I'll implement that separately and put it somewhere as a draft.

Awesome, thanks! I second your reasoning - while I haven't tried your commits in Openshift yet, your solution should be sufficient to get he imgae working!