I think in the previous PR it was discussed that this is a breaking change and thus must be deferred until 2.0. But you can just change the target branch from master to dev-2.0.

My bad, fixed it. Thanks @brancz

Just a stub as I'll forget about this, but it might be worth noting the fsGroup spec in Kubernetes in docs somewhere to fix the perms. https://kubernetes.io/docs/concepts/policy/pod-security-policy/

Anything further speaking against merging this?

To anyone who comes across this:

The correct UID would be 65534

$ docker run -it --rm --entrypoint sh prom/prometheus:v2.0.0

/prometheus $ id
uid=65534(nobody) gid=65534(nogroup)

Yep for me it is also 65534.
/prometheus $ id
uid=65534(nobody) gid=65534(nogroup)

Nobody is a very bad choice. To mount the data directory as a volume I have to give write permissions on my host to nobody, which is 'nomen est omen' should not have write permissions to any directory.

It doesn't mean you should run it as that user, but that you can run it as any user/group combination, giving you the possibility to choose permissions rather than the image forcing you into some seemingly random UID/GID combination.

Isn't it a pretty standard practice to run a docker container processes as root? In this configuration, using attached volumes becomes tricky compared to most every other docker container I've worked with. Basically, I need a startup script to make sure Prometheus has write access to its data volume