Cannot enable `nextcloud.defaultConfigs` without also setting `nextcloud.configs`

[CafeLungo]

Describe your Issue

The helm chart does not seem to allow you to configure the nextcloud.defaultConfigs options without also setting values in the dict nextcloud.configs: {}. This is due to the conditional here: https://github.com/nextcloud/helm/blob/main/charts/nextcloud/templates/config.yaml#L1

Logs and Errors

N/A, just describing the results from the helm deploy with the values provided below.

Describe your Environment

• Kubernetes distribution: Talos 1.10.3

• Helm Version (or App that manages helm): ArgoCD v2.14.6+fe2a6e9

• values.yaml:

nextcloud:
  defaultConfigs:
    imaginary.config.php: true

imaginary:
  enabled: true

Additional context, if any

These values are from the helm docs for enabling imaginary. Upon digging into it further, the config file never got created in the configmap, and the entire configmap is not being created, due to the conditional at the top.

[volker-raschek]

@wrenix, can be labels as bug. I had the same problem.

My expectation is that I can enable one of the defaultConfigs without to have one item in config defined.

In addition, helm chart creates the standard configuration files in the config directory, but with a list of configuration files enabled by default. For example, S3 for AWS storage. The maintainer of the Helm Chart has no idea in which environment the user is deploying Nextcloud. So how can S3 be enabled by default?

I think it's good to have this option to enable default configurations. However, these should be used as opt-in rather than opt-out - set it for all default configs to false

Unfortunately, the current implementation also leads to a drift. If a standard configuration, let's take S3 as an example again, is deactivated, the snippet remains in the config directory.

Instead of creating the configuration file there, why isn't it integrated into the file system via a projected volume? This would ensure that if the user removes it, it is also removed from the file system.

[wrenix]

Normally you do not need the defaultConfig, because the files are already part of the container image: https://github.com/nextcloud/docker/tree/master/32/apache/config so all defaultConfig is per default enabled.

imageinary is special, because that is not part oft the container image.

To S3 the defaultConfig PHP script checks eng variables like OBJECTSTORE_S3_BUCKET before it take any action

[volker-raschek]

Why do we than support the option to overwrite it manually?

[wrenix]

Why not, there is always a Person / setup who want to change it.

[volker-raschek]

Yes, you are absolutely right, but would it not enough to support nextcloud.config? The user can easily overwrite it by defining the key. For example nextcloud.config["redis.config.php"].

[Timoses]

See also the following discussion: #114 (comment)

I believe one issue (and potentially the initial motivation why defaultConfigs was even added to the helm chart) is that the nextcloud container entrypoint will never initialize the configs directory because it requires it to be empty. However, when we mount configs into it, it is no longer empty and Nextcloud Container will not initialize the directory.

With above linked comment I'm trying out a new approach.