kubeconform: '/spec/postgresql': got null, want object

[jkleinlercher]

With this chart a not conform cluster resource gets created. It works on the cluster, but kubeconform says it is against the schema:

stdin: Cluster release-name-cluster is invalid: problem validating schema. Check JSON formatting: jsonschema validation failed with 'https://raw.githubusercontent.com/suxess-it/kubriX/fix/kube-conform-alerts/kubeconform-schemas/postgresql.cnpg.io/cluster_v1.json#' - at '/spec/postgresql': got null, want object
Error: Process completed with exit code 1.

[dosubot]

Hi @jkleinlercher! I'm Dosu and I’m helping the charts team.

This happens because the Helm chart always emits a spec.postgresql section, but if none of its subfields are set in your values.yaml, it gets rendered as null in the manifest. The CloudNativePG CRD and kubeconform expect this field to be an object, not null, so validation fails—even though Kubernetes itself accepts it and the cluster works.

To fix the kubeconform error, make sure at least one subfield under cluster.postgresql is set in your values.yaml. The simplest way is to add:

cluster:
  postgresql:
    parameters: {}

This ensures spec.postgresql is always rendered as an object, satisfying the schema requirement. You can also set any other subfield (like pg_hba, pg_ident, etc.) if you need those features.

If you want a more robust solution, you could adjust the chart template to always emit an empty object for spec.postgresql when no subfields are present, but setting a default like above is the quickest workaround. This pattern applies to other fields too—avoid nulls by providing default values or using Helm conditionals. More details and discussion are in this issue and template reference.

If you want help crafting a minimal values.yaml, just share what you’re using!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jkleinlercher]

@dosu , Does

cluster:
  postgresql:
    parameters: {}

mean, all default parameters are still in place or do they get overwritten somehow?

[dosubot]

Setting parameters: {} means no user-supplied PostgreSQL parameters are set, so all operator and version-specific defaults remain in place and nothing is overwritten. User parameters only override defaults where specified; an empty object does not remove or change any defaults. Some parameters (like archive_command, listen_addresses, ssl, port, etc.) are always fixed by the operator and cannot be changed by user configuration, regardless of what you put in parameters. More details are in the official docs: CloudNativePG PostgreSQL configuration.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jkleinlercher]

@dosu

Unfortunately I still get

✖ stdin: Cluster release-name-cluster is invalid: problem validating schema. Check JSON formatting: jsonschema validation failed with 'https://raw.githubusercontent.com/suxess-it/kubriX/fix/kube-conform-alerts/kubeconform-schemas/postgresql.cnpg.io/cluster_v1.json#' - at '/spec/postgresql': got null, want object

[dosubot]

This happens because the Helm chart template uses conditionals that skip rendering all subfields under spec.postgresql if they're empty, so even with parameters: {} set, Helm treats it as empty and outputs postgresql:, which YAML interprets as null. This fails kubeconform, which expects an object, not null (details).

To work around this, set at least one non-empty subfield under cluster.postgresql in your values.yaml. For example:

cluster:
  postgresql:
    pg_hba:
      - host all all 0.0.0.0/0 trust

This ensures spec.postgresql is rendered as an object and passes schema validation. If you want a more robust fix, the chart template needs to be updated to always emit an empty object for spec.postgresql when no subfields are present (discussion). Until then, the workaround above will resolve the kubeconform error.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jkleinlercher]

@dosu

What are the default max_connections?

Then I can set max_connections without changing the default behavior.

Example:

postgresql:
      parameters:
        max_connections: "50"

[dosubot]

The default max_connections in CloudNativePG is not set by the operator, so it inherits the upstream PostgreSQL default, which is 100 for most versions. If you set:

postgresql:
  parameters:
    max_connections: "100"

you will preserve the default behavior for most clusters¹.

Note: If you are restoring from a backup, the effective max_connections may be set by the value recorded at cluster initialization (initdb) or in the backup, which can sometimes be lower (e.g., 10) and will override your user setting during recovery². For normal (non-recovery) clusters, setting it to "100" matches the default.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

Footnotes

1. Operator config does not override max_connections, so it falls back to PostgreSQL's default of 100 ↩

2. During recovery, the operator enforces max_connections from pg_controldata, which may be lower than your user setting ↩