Closed lindhe closed 9 months ago
I would say "it depends": this is a classic Folder-by-type or Folder-by-feature question.
If we remove most of the services, and add the chart's dependency of each, then the InvenioRDM chart might become small and another folders structure might make more sense.
Anyway, I have personally nothing against this, I am ok with this change if it brings clarity.
I agree, this is 100% a subjective question. There's no functional difference. The only reason I suggested it is that the folder-by-feature structure happens to have caught on in many prominent Helm charts [1, 2, 3, 4]. So that's what I was expecting to see when I had my first look at this project, and so will many others, I believe.
While I do not think that this is super important, it is a change that will collide with most other changes. So it's probably best to do this immediately to get it out-of-the-way before we make other changes.
Great! I'll get on this!
I'd like to get this minor refactoring out-of-the-way before fixing the structure: https://github.com/inveniosoftware/helm-invenio/pull/89
With that change, it will be easier to split the secrets into separate directories.
It is unclear to me what the structure inside of the
templates/
directory is. Whiledeployments
,persistentVolumeClaims
andservices
sounds like Kubernetes resource types,configurations
does not. And inside ofdeployments
we findrouting.yaml
which contains threeRoute
resources and anIngress
resource; not a Deployment resource! As a new user, I find this pretty confusing.A common pattern for structuring complex Helm charts is to keep one subdirectory per subsystem, with the file names being descriptive of the Kubernetes resource type within. I propose we adopt something like that. For example, like this: