Introduce Helm Chart

[pschichtel]

I can offer to add my helm chart to this repo including a workflow that uses chart-releaser to publish chart releases to gh-pages.

[TheAnachronism]

Like mentioned in the original issue eikek/docspell#2502, I've got a helm chart as well:
https://github.com/TheAnachronism/docspell/tree/helm-chart/kubernetes/helm/docspell

The question now is just, with which one do we want to start?
I have some things I want to rework with it, like extraEnvs or extra volume mounts, etc. All those common things you see in other charts for further customization of the deployment.

Another thought I had was about the actual configuration. My chart right now translates the settings in the values.yaml file into environment variables and passes them to the docspell container.
One approach I've come across with setting up such configuration is with an init-container that actually writes the used config file (see the helm chart for gitea). That way, environment variables wouldn't be filled up with all the configuration options.

I guess it depends on what philosophy one follows, and I just think configuration should be done purely via values.yaml and not pass the entire value for the application configuration file.

[pschichtel]

my approach to configuration for docspell was kind of hybrid: The full configuration file is in the values.yaml, but it's templated and the goal is, that normal setups should all be configurable through specific options in the values.yaml directly. More advanced configuration could be done by allowing users to add config snippets that are included in the config (or by having a specific folder in the container that contains files to be included, HOCON supports this). Finally for full control, people can replace the entire config template with their own.

I went with this approach because docspell has quite a few options with a lot of variation possible.

The template is currently hardcoded to a few assumptions I made for my setup that are easily fixable.

[pschichtel]

A few more differences between the charts:

1. you modeled joex and reserver as a deployment, I want for a statefulset + headless services (primarily for stable hostnames)
2. you include portgres as a dependency chart, I intentionally don't (needs to be updated and usually not a useful bias when it comes to databases)
3. you include a solr deployment, I don't (I don't use solr in my setup)
4. you support existing secrets, I don't (I use encrypted values files for secrets)

There is probably more, but these seem important.

(1) seemed like a technical necessity to me, I wonder: Does your joex properly continue jobs on restart? Also: Get old joex/restservers cleaned up in the database or do they accumulate?

(2) I'd be fine with including the chart, someone needs to keep it updated and then someone will have to tell people to do major version upgrade of postgres. I won't be using it and I wouldn't recommend using it, people will eventually have to put some thought into their database setup, I'd prefer pushing people sooner than later :)

(3) I wouldn't want to maintain a solr deployment, when there is probably better charts around and an official operator as well. Also the same as for (2): Someone needs to update it and tell people about potential manual steps.

(4) definitely nice to have existing secret support (e.g. for sealed secrets or external secrets).

[pschichtel]

I'd be fine starting with yours and iterating on that.

[TheAnachronism]

OK so,

• I agree with the dependency charts. My chart has it right now, as I basically just modelled it after the Gitea chart.
  Tbh. I agree with removing these dependencies and letting the users handle their own deployment for these services. (Personally, I have a Postgres cluster running with the Zalando operator, so I wouldn't have used the dependency in a production deployment either).
• I have a strong need for the existing secrets, due to storing everything inside 1password and using its connect feature to inject them into the cluster when deploying the secrets with ArgoCD.
• About the technical necessities; when I wrote that chart, I just wanted to get it going for now. I agree that joex should probably be reworked into a statefulset.

[TheAnachronism]

About the way the configuration is done, I agree that the end result should probably be the config file itself, rather than a ton of environment variables.
I still would like to have a large part of the docspell configuration be possible purely with the values.yaml file.

Maybe template it as a config map / secret and then mount it into the container?

[TheAnachronism]

@eikek is it just me, or can we not add anything to this repo? When trying to do anything or even create a PR, the repo is just empty the entire time.
Maybe we need an initial commit from the owner?

[pschichtel]

@TheAnachronism I was able to push the initial commit, what was your error output?

[TheAnachronism]

Just nothing, I couldn't interact with anything except issues and such. As soon as it came to the repo or code section, it just showed that the repo was empty.

Well, weird, now I can see something too.

[TheAnachronism]

Wait. Now it shows me that I was invited (even though I already accepted that one), but that results in an error that the invitation has already expired.
Huh

[eikek]

oh very strange - in the settings it didn't show you @TheAnachronism as a maintainer or any collaborator. I just added you again.

[TheAnachronism]

Thanks, @eikek, now everything should work as intended.

[pschichtel]

@TheAnachronism are still interested in adding your helm chart here? if not I could go ahead and add mine as a starting point.

[pschichtel]

I migrated my helm-chart including history and initialized the chart releaser. @eikek can you please enable gh-pages on the repository to host the helm repo?

[pschichtel]

@eikek nvm, turns out I can already do that myself :)