Conversation
ryanartecona
force-pushed
the
ra/standalone-dbc
branch
from
a1122d3 to
783dfac
Compare
| @@ -0,0 +1,2 @@ | |||
| dbconnector: | |||
There was a problem hiding this comment.
glad to see this feature of testing with random extra charts was useful lol
| # cpu: 2048m | ||
| # memory: 4096Mi | ||
|
|
||
| config: |
There was a problem hiding this comment.
did you mean to set this config intentionally? I'm surprised to see such a high default postgres max pool size, especially on the dbc deployment, as that would be specific to the Postgres connector which isn't global (also I believe the Postgres connector uses a different env var).
There was a problem hiding this comment.
putting the config here was an intentional refactor from the internal fork I used as reference, yes. but the default values I don't have strong opinions about, these are mostly guesses. what do you think they should be?
I did confirm this templates out to the correct env var (DBCONNECTOR_POSTGRES_POOL_MAX_SIZE), which defaults to 10 in our code if unspecified. should I just use that?
| - name: DB_CONNECTOR_HOST | ||
| value: http://{{ template "retool.fullname" . }}-dbconnector | ||
| - name: DB_CONNECTOR_PORT | ||
| value: '3002' |
There was a problem hiding this comment.
nit: would consider making this configurable with a default of 3002, unless we hardcode the backend port as well (I think that should also be configurable, but if it's already there then we can just make that improvement separately).
There was a problem hiding this comment.
done! I couldn't do it exactly how backend does it, but it's at least configurable.
| ports: | ||
| - protocol: TCP | ||
| name: http-server | ||
| port: 3002 |
There was a problem hiding this comment.
nit: similarly to the env vars, would make this configurable if possible
| value: {{ join "," $serviceType }} | ||
| {{- if $.Values.dbconnector.enabled }} | ||
| - name: DB_CONNECTOR_HOST | ||
| value: http://{{ template "retool.fullname" . }}-dbconnector |
There was a problem hiding this comment.
this would point workflows-backend at the generic dbc deployment -- is it intentional that we aren't creating a workflows-dbconnector deployment here?
There was a problem hiding this comment.
it's intentional, yes, but not unchangeable. I think splitting dbconnector out of main backend is likely the main scalability unlock for large single-tenant deployments, and we're only just now adding it to retool-helm. going even further and splitting out a workflows-dbconnector from the main dbconnector seems premature, given that workflows doesn't need its own dbconnector to function and we do that mainly for scale reasons in our multi-tenant cloud.
ryanartecona
force-pushed
the
ra/standalone-dbc
branch
from
783dfac to
f7172b0
Compare
slaminad
force-pushed
the
ra/standalone-dbc
branch
from
a89c5e3 to
91da358
Compare
slaminad
left a comment
slaminad
left a comment
There was a problem hiding this comment.
lgtm. tested on athelas
|
since we saw that the msh athelas was working the other day, i think this should be good to go? |
ryanartecona
force-pushed
the
ra/standalone-dbc
branch
from
91da358 to
906dea3
Compare
3 participants
Allow dbconnector to run as a standalone deployment for scale & resource flexibility for large deployments.