chaoss
facade cloned repositories in dirty state
When restarting augur, it is observed that all the permissions in cloned facade repos get set to 777. This was observed via git status while investigating a hang with facade. See the Slack thread.
The line responsible appears to be https://github.com/chaoss/augur/blob/7f58fbc8075d228c9d427f86e577af31e4a49520/docker-compose.yml#L89
this post_start section was only added for improving openshift support.
to reslove this issue:
- [ ] create a PR that removes these lines.
- [ ] create a new issue that documents the need to re-introduce these lines in a way that fixes the original permissions issue with running in openshift, but also doesnt cause this issue with non-openshift installs.
CC @JohnStrunk
As far as I understand,
chmod 777 /facade /logs /config /cache
may be a much safer option: changing the permission of the root directories of the volumes is needed to start the data collection at all, otherwise nothing can be written at all inside /facade, but recursively resetting permissions of all files at every restart is really a bad idea, because it causes the problems with had with repository cached under /facade then becoming dirty.
yeah I agree. @JohnStrunk may have more context on why recursive chmod was chosen here. I suspect it may be to handle cases where existing facade directories, potentially with ownership set to some other user, are mounted (especially into an openshift environment where the UID is likely random)
Give it a try w/o the -R. As long as those directories are empty on the 1st run of the container, it should be fine.
The uid is stable across runs, so as long as it starts up initially, it should keep working. The compose file isn't used in OCP/Kube, so you're not going to break anything there.
I don't remember why I put the -R in. It may have been a poor attempt to not break folks that had been running as root. A better solution to all of this would likely be a chown -R to the uid/gid of the container as this would handle it if a user decides to switch to a different uid/gid--- not really sure why one would do that, but it's another idea.
