[jure965]

Replaces built in bitnami helm chart with official valkey helm chart. This mimics the configuration from official docker-compose deployment of Weblate, which now uses valkey by default.

Introduced cache key in values.yaml for weblate cache configuration. This generalizes configuration for folks wanting to use externally managed redis or valkey and also decouples configuration from sub-chart configuration.

By default, built-in valkey deployment is enabled without any auth. I've also tested with auth enabled with inline passwords and also with existing secret references.

As a side note, redis/valkey clusters are not yet supported, only standalone instances. This is a limitation of the python client libraries used in weblate.

Comments, questions, suggestions are welcome.

[Mart-Kuc]

Hi @jure965 , thanks for the PR.

I would like to raise a discussion about this change.

Why do we want to migrate from the default Redis to the default Valkey?

• Is the problem with Redis license? As far as I know, the Redis license is more restrictive now, but I am not aware of anything new that would currently cause a problem for us.
• Are there any technical or operational reasons for preferring Valkey?
• Is there any maintenance benefits from making Valkey the default?

@nijel what is your suggestion from application point of view?

[nijel]

Weblate prefers Valkey in the documentation now, but both should work. The main reason back then was the license change in Redis which might be problematic to some users (I don't recall the details). Valkey is also faster in some benchmarks, but I don't think this would be measurable on a typical Weblate instance.

[jure965]

Hey @Mart-Kuc,

hopefully I can answer some of your questions. The main reason for Valkey is that official Weblate docker compose deployment variant already uses Valkey image by default. Another reason is bitnamilegacy images are no longer getting updates, increasing security risks.

As for technical or operational reasons and maintenance benefits, Valkey provides simple official helm charts. For Redis I only found some unofficial charts and their enterprise offerings.

I intend to provide further pull requests that will also replace the bitnami postgres chart. And in the future also introduce a scalable split-mode deployment for Weblate on Kubernetes, official docker compose for split-mode is already a very good example. That said, for split-mode might be better a separate helm chart. I'm open for discussion.

[nijel]

Going back to this, I think this is good move in general. Valkey official chart is move out of Bitnami charts which are problematic and brings the dependency in sync with upstream. But I don't see if this is something that is likely to break existing installations (Valkey cannot import persisted data from recent Redis releases).

[jure965]

Yes, moving from redis to valkey presents a breaking change. Hopefully people are aware that v0 chart releases often make breaking changes. We can give some notice in the changelog.

[Mart-Kuc]

Understood, from your point of view, migrating to Valkey makes sense.
I am totally fine with these changes. I just have question:

How should we announce the breaking change? If I understand correctly, we don't need to migrate existing Redis data. Or are there any scenarios in which data migration would be required?

[Mart-Kuc]

Why do we need to split cache and valkey into separate keys in the values.yaml? Could we keep everything under a single key, e.g. Values.valkey.db, instead of Values.cache.db?

[jure965]

Under cache key in the values.yaml is the configuration of client in the Weblate, and valkey key holds the values passed to the Valkey helm chart. It is intentionally split so helm chart is useful for folks who deploy with externally managed in-memory database and disable built-in Valkey deployment.

Please also see #369 - instead of splitting the chart, we allow enabling or disabling built-in Valkey deployment via valkey.enabled key in values.yaml while simultaneously allow configuration of the client independently. This is pretty much well known practice in helm world.

[jure965]

Just realized I have probably not really answered your question. I propose having client configuration separated as I have seen it done like that in many other helm charts before and am not opposed to the idea of having client and server configs separate.

[jure965]

How should we announce the breaking change?

Usually breaking changes are announced upon release in the release notes.

If I understand correctly, we don't need to migrate existing Redis data. Or are there any scenarios in which data migration would be required?

Good question, unfortunately I don't have much insight into what is getting stored in the in-memory database by Weblate to warrant persistence. Celery can use it as a queue and it can Django can store page renders to save on response time. Actual developer might have better answer here.

[nijel]

The persisted data are task queues (which are anyway not guaranteed to be compatible across upgrade) and statistics cache (which can be recalculated).