initdb.scriptsConfigMap might be using a non-resolvable default

[pat-s]

Thanks for this chart!

I think the following line must be updated, the default name resolution didn't work in my case

matrix-sliding-sync-chart/charts/matrix-sliding-sync/values.yaml

Line 188 in 541b2dd

scriptsConfigMap: "{{ .Release.Name }}-postgresql-initdb"

I.e. {{ .Release.Name }} didn't result in a name which could be resolved. I finally set it to scriptsConfigMap: "sliding-sync-matrix-sliding-sync-postgresql-initdb" because fullName (with the chart default) also didn't work.

Did not spend too much time looking into it, maybe you want to 🙃

[jessebot]

Thanks for pointing this out! Full name should work because that's what's listed here:

matrix-sliding-sync-chart/charts/matrix-sliding-sync/templates/initdb-configmap.yaml

Line 5 in 541b2dd

name: {{ include "matrix-sliding-sync.fullname" . }}-postgresql-initdb

Perhaps I can add an option to deploy the initdb configmap optionally and allow the user to set the name themselves? 🤔 I'll play with it unless you have any further suggestions or would like to work on this 🙏

[jessebot]

How does this change feel? It removes the configMap entirely and instead templates out the script directly:

matrix-sliding-sync-chart/charts/matrix-sliding-sync/values.yaml

Lines 182 to 195 in 25d062e

	# primary database node config
	primary:
	# -- If using an external Postgres server, make sure to configure the database
	# ref: https://github.com/matrix-org/synapse/blob/master/docs/postgres.md
	initdb:
	# -- Map of initdb scripts. Specify dictionary of scripts to be run at first boot
	scripts:
	# -- note, if you change postgresql.global.postgresql.auth.username,
	# or postgresql.global.postgresql.auth.secretKeys.userPasswordKey,
	# please also change it in the 3 lines of this script
	matrix_sliding_sync.sql: |
	CREATE DATABASE matrix ENCODING 'UTF8' LOCALE 'C' TEMPLATE template0 OWNER syncv3;
	GRANT ALL PRIVILEGES ON DATABASE matrix-sliding-sync TO syncv3;
	GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO syncv3;

Otherwise, we have to keep hardcode a specific name for the ConfigMap, which could require templating in the values.yaml, and that really shouldn't be done anyway as that's almost always a recipe for failure if a user uses something like Argo CD or another gitops solution that also supports goTemplating. The other alternative, which I mentioned earlier is to have the user specify a name of a configMap and then we deploy the configMap with that name, but that also means that a user can't deploy their own configMap, which is kind of the state of things right now. I think this is a fair compromise. We could also keep this, but comment it out and leave a note to un-comment it to do basic initDB script creation?

[pat-s]

Full name should work because that's what's listed here:

Yes, I thought so as well - likely I made a mistake then. At least, .Release.Name didn't work 😄

How does this change feel?

Not much different than the previous one (when it is fixed). Not meant in a negative way.

One thing you could consider (which I see in other charts usually) is that the full initdb logic must be provided in a secret (with an example commented included).
Right now you have the downside of having a dependency on username and database as noted - which will at some point cause troubles.

[jessebot]

Thank you for the feedback :)

What if we commented what I have changed in that PR above and added the note that it needs to be uncommented if you'd like to do the initial database setup as you suggest? We can also mention in the comment that you're also free to store this info in a ConfigMap or Secret and point to the other parameters you'd configure for using those? Have I hit the best of all three worlds? 😄

[jessebot]

Looks like the sliding sync proxy is being deprecated:

We will be decommissioning the sliding sync proxy next week (21/11/2024) and Element are removing client support in mid-January (17/01/2025).

https://matrix.org/blog/2024/11/14/moving-to-native-sliding-sync/

I will be archiving this repo going forward and closing this issue.