Supprt Dendrite in polylith mode

[anthr76]

Details

Helm chart name: Dendrite

Describe the solution you'd like: A dendrite deployment using k8s-at-home library charts

There has been discussions among @S7evink, and @Jonnobrow I about support dendrite in a polylith deployment model. This issue should track it's progress. The current contigency plan is to add each component as a dependency to the current dendrite deployment.

Progress is being made here and if you'd like to be added as a contributor to help complete the dendrite polylith chart please contact me via discord or matrix via: anthr76#1885 anthr76:mozilla.org

A rough outline of what needs to happen

• [ ] Create simple microservice deployments exposing only a service and container deployment sepc for all of the components of dendrite
• [ ] Add a switch in the values of the existing dendrite deployment to enable polylith or monolith
• [ ] Suppport private key generate and helm dependencies for postgress and nats

This chart release should be blocked until a NATs release is cut from dendrite and we should template the config around dendrite's mono config version 2

Anything else you would like to add:

Additional Information:

A chat log about efforts.

anthr76 Hi there jonnobrow. S7evink and I were interested in coming together and adding polylith support to the Kubernetes at home dendrite chart. Would this something you're interested in? jonnobrow Hi, that sounds great. I'm more than happy for you both to take the lead on it and I'll help out if needed 🙂 s7evink I'll need to understand the layout of k8s-at-home first, it is slightly confusing :D jonnobrow Yeah definitely :) its worth checking out the docs on creating a new chart. They run you through the tools you'll need and introduce using the library chart templates.

For implementing polylith we will almost certainly need some advanced logic as there will be multiple deployments which is not the default for most things.

If you have any questions about getting started give me a shout and I'm happy to help :)

Also perhaps look at the library chart to see what is available in the way of templates so you don't do any work thats already been done for you :) Finally, for kafka, I think we can include it as a dependency like postgres or the common chart since there is a chart maintained by bitnami s7evink Will have a look, thanks :) I don't think we need Kafka, the next release will require NATS instead of Kafka. :) anthr76 I wonder if it's possible if we can create a branch off a forked repo and all make pushes to it. That should be possible? Indeed I just invited both of you to my forked repo. Feel free to make pushes on the feat-poly branch anthr76 image.png This is a note from onedr0p a admin for KaH jonnobrow Interesting, I supposed we could keep each components chart fairly simple (especially with config) and do any clever config logic in the parent polylith chart? Otherwise I worry we would be duplicating a lot of stuff Another approach might be to have a single component chart which we can parameterize and include as a dependency multiple times with dependency aliasing: https://helm.sh/docs/topics/charts/#alias-field-in-dependencies anthr76 jonnobrow Another approach might be to have a single component chart which we can parameterize and include as a dependency multiple times with dependency aliasing: https://helm.sh/docs/topics/charts/#alias-field-in-dependencies This is exactly what I was thinking, and made what I think should be a completed implementation of the clientapi jonnobrow Okay great 👍 I'll take a look soon, there are some other bits I need to update/fix with the monolith chart and some refactoring that might help us in implementing polylith so I will try to do that over the next few days and keep you both updated.

Also, would it be possible to create an issue to track the work we are doing towards polylith and do any planning there?

anthr76 Sure! I'll get one opened, and try to get these subcharts completed tonight. It would be great if we can get a release pushed to dendrite to support NATs so we can update the config file

[Jonnobrow]

We may not need to create individual component charts as they will be very similar and mostly duplicate, I think it is also fair to say they are unlikely to be deployed on their own?

Using dependency aliasing we could do something along these line (only client_api is shown, similar concept for other components):

# Chart.yaml
dependencies:
    - name: common
       ...
       alias: client_api
       condition: dendrite.polylithEnabled

# values.yaml
client_api:
    image:
        repository: matrixdotorg/dendrite-polylith
        tag: "v0.5.1"
    service:
        main:
            ports:
                http:
                    enabled: false
                internal:
                     enabled: true
                     port: 7771
    config:
         # Move the config from .Values.dendrite.components.client_api for better readability

dendrite:
    polylithEnabled: true

# templates/common.yaml
{{- if .Values.dendrite.polylithEnabled }}
    {{- include "common.values.setup" .Subcharts.client_api -}}
    ...
{{- else }}
    {{- include "common.values.setup" . }}
{{- end }}

...

{{- if .Values.dendrite.polylithEnabled  }}
    {{- include "common.all" .Subcharts.client_api  -}}
    ...
{{- else }}
    {{- include "common.all"  . }}
{{- end }}

[anthr76]

Indeed dependency aliasing seems like a better solution and something I learned about. We should move forward with that approach.