Support for Redis Enterprise on externalRedis

[giladd123]

Currently, the chart uses only one Redis instance, with two logical DBs (one for the app and one for celery). This works on the oss version of Redis as it provides all logical DBs under the same endpoint, with DB ids between 0-15.

On Redis Enterprise, the logical DBs are completely isolated. This means a different port for each logical DB, a different username and password, and even isolated IO.
Reference

As it stands now, the chart can't support this behavior. I'm opening this issue for consulting what solution will be the best for this chart, and after one is decided upon, I'll gladly create the changes and push them.

The current configuration looks like so:

externalRedis:
  enabled: false
  host: "redis.example"
  port: 6379
  username: ""
  password: "difyai123456"
  db:
    app: 0
    celery: 1
  useSSL: false
  sentinel:
    enabled: false
    masterSet: "mymaster"
    sentinels:
      - "sentinel1.example:26379"
      - "sentinel2.example:26379"
      - "sentinel3.example:26379"
    password: ""

This prevents setting different port/host/username/password for the app and for celery.

From how I see it, a better approach would be like so:

externalRedis:
  app:
    db: 0
    ...
  celery:
    db: 1
    ...

This approach raises a concern regarding the current format. Changing the format to look like so would break the current values.yaml files for all users using externalRedis.
We can keep support for the current format, with the format suggested, but it will make the chart a bit harder to read, and the values difficult to understand.
values would look like so:

externalRedis:
  app:
    ...
  celery:
    ...
  enabled: false
  host: "redis.example"
  port: 6379
  username: ""
  password: "difyai123456"
  db:
    app: 0
    celery: 1
  useSSL: false
  sentinel:
    enabled: false
    masterSet: "mymaster"
    sentinels:
      - "sentinel1.example:26379"
      - "sentinel2.example:26379"
      - "sentinel3.example:26379"
    password: ""

And the chart will prefer to take externalRedis.app/externalRedis.celery, but, if they're not available, it'll take externalRedis.
Do you think ignoring the old format is a viable option? Or should we keep both?

I'd love to hear your opinions on this issue, and I'll get on to working on a solution!

[BorisPolonsky]

Thanks for the clarification. We will look into this problem once we have time.

Meanwhile, the workaround is to enable externalRedis for non-celery configuration and override things for celery with api.extraEnv and worker.extraEnv.