[fix] Add default multiplayer ingress rule#205
Conversation
lukefoster11
left a comment
There was a problem hiding this comment.
Looks good, just had one question before merge
| # Paths to route to multiplayer pods; defaults to /api/multiplayer. Can specify both path and port. | ||
| ingress: | ||
| # This conditional is dependent on multiplayer.enabled. | ||
| enabled: true |
There was a problem hiding this comment.
I know this can be set to false but by default could this be a breaking change for anyone who has already set up this ingress rule?
There was a problem hiding this comment.
It will be, which I considered and decided to keep this way. I think there's no real way to make this default-true moving forward, without breaking folks who have the ingress rule already. I believe that what will happen is that people will run into an error on helm upgrade due to the duplicate routes, so when I tag the release for this PR I'll make a note in the release to expect the breaking change.
There was a problem hiding this comment.
Gotcha, yeah don't know a smooth alternative so this makes sense
| enabled: true | ||
| paths: | ||
| - path: /api/multiplayer | ||
| port: 80 |
There was a problem hiding this comment.
The multiplayer service uses 3009 as the default port, should that be set here?
There was a problem hiding this comment.
No, this points at the entry port for the service, which is 80: https://github.com/tryretool/retool-helm/blob/main/charts/retool/templates/deployment_multiplayer_ws.yaml#L13
The destination port for the multiplayer deployment is hardcoded to 3001 here (probably should have been left at 3009 rather than introducing potential port conflicts, but that isn't relevant for this change), with another hardcoded env var pointing the container to port 3001: https://github.com/tryretool/retool-helm/blob/main/charts/retool/templates/deployment_multiplayer_ws.yaml#L78
d837016 to
7a5bc22
Compare
Addresses #199, aims to automatically create an ingress rule, if multiplayer is enabled, to point requests for
/api/multiplayerto the multiplayer pod. To avoid conflicts with folks who already have this ingress rule set, this automatic rule can be disabled usingmultiplayer.ingress.enabled=false.Tested by applying to our test cluster, which created a new (inaccessible) ingress, which looks like this (redacted hostnames just in case, but they shouldn't be sensitive):


I also added these values to the
values.yamlfile: