Do not to use --stdout for relay credential generate

[aminvakil]

First brought up in #1251 (comment)

[aminvakil]

relay tries to create credentials.json with 10001:10001 owner/group and gets permission denied.

   2022-01-23T12:25:00Z [relay_log::utils] ERROR: could not write config file (file /tmp/relay/credentials.json)
    caused by: Permission denied (os error 13)

[aminvakil]

So we can see what uid/gid is running docker, try to change uid/gid of relay_directory to 10001:10001 to let relay write on it, then change it back to uid/gid of user running docker, but this has a couple of disadvantages.

1. It's hacky!
2. If something happens during these commands or relay docker command breaks, this folder will remain in unwanted condition (10001:10001 uid/gid).
3. Changing ownership needs sudo privilege which some user may not have (although the workaround would be something like docker run --rm --volume "$(pwd)/relay:/tmp/relay" alpine chown -R 10001:10001 /tmp/relay)

But this is what I have thought of, @BYK @untitaker @chadwhitacre What do you think about this?

Is it something obvious I'm missing which can handle this situation easily? Or redirecting and using --stdout is better than this?

[aminvakil]

Created credentials.json is different now:

{
  "secret_key": "JNGDJB-lmrJskamELp9Ge67ljccSKHKFLcRb5cBeHrA",
  "public_key": "vu58jZocizKvK6v2b6Q85aOFZny3mzdCvXBr1IUiiMg",
  "id": "cd11c1cc-8b5c-4adc-89dc-c1c20beb2e1e"
}

It used to be like this:

{"secret_key":"JNGDJB-lmrJskamELp9Ge67ljccSKHKFLcRb5cBeHrA","public_key":"vu58jZocizKvK6v2b6Q85aOFZny3mzdCvXBr1IUiiMg","id":"cd11c1cc-8b5c-4adc-89dc-c1c20beb2e1e"}

[BYK]

Seems like relay is still complaining about not being able to read credentials: https://github.com/getsentry/self-hosted/runs/4913039350?check_suite_focus=true#step:5:1026

[BYK]

Why not put these in a custom entrypoint script and use $dcr instead?

[aminvakil]

Does this (1d7c7a7) look good?

[aminvakil]

Seems like relay is still complaining about not being able to read credentials: https://github.com/getsentry/self-hosted/runs/4913039350?check_suite_focus=true#step:5:1026

I've made a change trying to read it, and it seems that user running docker which is runner can read it, the only difference this PR is making is the structure which I don't know if it should be important or not.

https://github.com/getsentry/self-hosted/runs/4919429511?check_suite_focus=true#step:4:526

[BYK]

is making is the structure which I don't know if it should be important or not.

Both are JSON blobs, just one is better formatted. Should be fine.

[BYK]

I'd say, in the final version, we can just use the mounter relay config dir for this?

[aminvakil]

Can you elaborate please?

[BYK]

We already mount the relay directory for the relay service and set that as the config folder so you should not need the --volume "$(pwd)/$RELAY_DIRECTORY:/tmp/relay" part and --config /tmp/relay part.

[aminvakil]

We have this:

self-hosted/docker-compose.yml

Lines 340 to 358 in da8f490

	relay:
	<<: *restart_policy
	image: "$RELAY_IMAGE"
	volumes:
	- type: bind
	read_only: true
	source: ./relay
	target: /work/.relay
	- type: bind
	read_only: true
	source: ./geoip
	target: /geoip
	depends_on:
	kafka:
	<<: *depends_on-healthy
	redis:
	<<: *depends_on-healthy
	web:
	<<: *depends_on-healthy

which mounts relay directory read-only and AFAICS there is no --config.

[BYK]

We can mount it as writable for that run but yeah, I get your point :)

[chadwhitacre]

@aminvakil Can we switch this to a draft PR if it's still under active development? 😶

[aminvakil]

@aminvakil Can we switch this to a draft PR if it's still under active development? no_mouth

Sure, sorry for the noise these past days.

[aminvakil]

Considering current changes in relay generation, this chowning and back is too hacky, I would say let's keep at is it for now, we can take a look at this later if we wanted to.