Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reevaluate the need for helm chart driven approach #22

Open
digihunch opened this issue Feb 3, 2023 · 2 comments
Open

reevaluate the need for helm chart driven approach #22

digihunch opened this issue Feb 3, 2023 · 2 comments

Comments

@digihunch
Copy link
Owner

digihunch commented Feb 3, 2023

Configuration of Traefik proxy requires its own maintenance and version change may break existing tests.
Use an Envoy-based ingress controller (e.g. Contour) can reduce this risk. Or just get rid of the Helm chart driven option

@digihunch digihunch changed the title retest all three approaches reevaluate the need for helm chart driven approach Feb 4, 2023
@barrettMCW
Copy link

Thanks for your work on Korthweb! Managing versions in this type of deployment can start to become a headache, which I think is why you usually don't see too many deployments in this style.

To me, kubernetes is all about services and the helm chart is about giving version control to those services. Typically all you would do is expose all the options a given application has, not being able to fully manage the configuration (orthanc.json) from the chart loses a lot of what I appreciate by using a helm chart. If an administrator wants to use encryption in the app (providing certificates to orthanc.json) they should be able to configure it from the helm chart, however if they want to have Traefik (or some other external app like Istio) encrypt it, that is beyond the purview of a typical base chart, it should be handled externally by an administrator by tapping into the k8s Service.

There's definitely a place for this kind of deployment, like what daskhub's chart does, but in that situation you typically want a base helm chart that you depend on. This creates nice separation of issues, and allows you to upgrade a base helm chart without necessarily updating (and breaking) the derivative chart.

If you ever decide to drop your helm support (or refactor your chart) feel free to point people to my fork. Traefik and PG are stripped out, but it has proper exposure for the orthanc.json as well exposure for envvars, volumes, and mounts. I am working on adding orthanc-auth-service to the chart, then I will fill out a readme with instructions, should have a proper repo ready by the end of the week. I personally plan on maintaining the fork for as long as I have this job, so it should be maintained for at least a few years, and it's likely to be picked up by the new me should I leave.

Again thanks a lot! This is a great project that saved me (and I'm sure plenty others) tons of time working on orthanc in kubernetes!

@digihunch
Copy link
Owner Author

thank you @barrettMCW . you're right the helm chart is trying to do too many things. should just focus on orthanc pods and parameterize db, storage, idp config, etc. i'll update in the next release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants