Conversation
Add complete OpenProject support with PostgreSQL and Redis dependencies: - Add OpenProject helmfile configuration with local chart dependencies - Configure OpenProject with OIDC authentication via Keycloak - Set up PostgreSQL database and Redis cache for OpenProject - Add OpenProject to all environment configuration files: - Global hostname and domain configuration - Database connection settings with derived passwords - Redis cache configuration - OIDC client authentication setup - Resource limits and autoscaling policies - Persistent volume claims for data storage - SMTP configuration for email notifications - Use OpenProject community chart v11.0.0 (app v16.4.1) - Configure ingress with TLS support for openproject.mb.test - Set up proper security contexts and network policies - Enable horizontal pod autoscaling for web and worker components The OpenProject application is now ready for deployment in demo and production environments with full integration into the mijn-bureau infrastructure stack.
Attempt to fix the seeder job.
Another attempt to fix an issue with seeder job
Another attempt to fix the seeder job issue.
This reverts commit dd98016.
Is that a hallucination? As far as I know, we do not use Redis for background jobs at all. Our background job processor (Good Job) is using Postgresql for all its duties. As far as I am aware, we do caching through Rails and use memcached for our own deployments, but (as far as I understand from our docs) would also support using Redis instead. But I don't think it would make sense to have both. |
NobodysNightmare
left a comment
NobodysNightmare
left a comment
There was a problem hiding this comment.
I couldn't meaningfully review the PVC part, due to lack of understanding of what OpenProject needs there.
I still added a couple of questions and I am comparatively sure that some of my comments will require a change.
| enabled: true | ||
| minReplicas: 1 | ||
| maxReplicas: 3 | ||
| targetCPU: 75 |
There was a problem hiding this comment.
I might be misunderstanding how Helmfile is working here, but I don't see that we are using any of these values when configuring the openproject/values.yaml.gotmpl. Are we really setting anything up here?
There was a problem hiding this comment.
They are used in the very end of the values file:
# Autoscaling configuration
{{- if .Values.autoscaling.horizontal.openproject }}
autoscaling:
hpa: {{ .Values.autoscaling.horizontal.openproject | toYaml | nindent 4 }}
{{- end }}
But, tbh, I'm not sure if the autoscaling values are correct, just copied from another apps in this file.
There was a problem hiding this comment.
Autoscaling is hard. I am not even sure if it's possible to do it properly without knowing the hardware we deploy to (since this is configuring CPU-based autoscaling.
What I usually saw happening is that a misconfigured autoscaling falls left or right:
- left: the deployment is always scaled to
minReplicas, because the requested CPU is too high to ever be reached - right: the deployment is always caled to
maxReplicas, because the requested CPU is too low to even be reached in idle
There was a problem hiding this comment.
We can leave these values as they are and let them decide for themselves whether to change them later 🤔
Update security defaults.
Update caching mechanism
Make OIDC configurable, remove smtp, resources, appInit to make it clean
shiroginne
changed the title
4 participants
📋 Summary
This PR adds OpenProject as a new application to the MijnBureau infrastructure, providing project management capabilities alongside existing applications like Grist, Keycloak, and Nextcloud.
✨ What's New
🎯 OpenProject Application