Remove useless default values for CRD

[fjammes]

Description

Removed default values from CRDs as they were causing issues with synchronization in ArgoCD. When Kubernetes stored the CRDs inside etcd, it stripped fields with default values, which led to ArgoCD being unable to reconcile the changes properly. By eliminating default values, we ensure that the synchronization process in ArgoCD works without issues.

Definition of Done Checklist

• Not all of these items are applicable to all PRs; the author should update this template to only leave the boxes that are relevant.
• Please make sure all these things are done and tick the boxes.

Author

• Changes are OpenShift compatible
• CRD changes approved
• CRD documentation for all fields, following the [style guide](https://docs.stackable.tech/home/nightly/contributor/docs/style-guide).
• Helm chart can be installed and deployed; operator works
• Integration tests passed (for non-trivial changes)
• Changes need to be "offline" compatible

Reviewer

• Code contains useful comments
• Code contains useful logging statements
• (Integration-)Test cases added
• Documentation added or updated; follows the [style guide](https://docs.stackable.tech/home/nightly/contributor/docs/style-guide).
• Changelog updated
• Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

• Feature Tracker has been updated
• Proper release label has been added
• [Roadmap](https://github.com/orgs/stackabletech/projects/25/views/1) has been updated

---

Let me know if further refinements are needed!

[stackable-bot]

All committers have signed the CLA.

[nightkr]

As @maltesander mentioned in #626, those CRD files are generated. This is something that would need to be changed in kube-derive, which should then trickle down into all our operators.

That said, if Argo gets confused by explicitly initializing empty values then that sounds like a bug on their side.

[fjammes]

Hi @nightkr , here is some detailed informations: this situation arises due to how Kubernetes handles default values in its API and the implications for tools like Argo CD. When a Kubernetes object is created, the API server automatically applies default values to fields that are not explicitly specified. However, these default values are not stored in etcd, the key-value store backing Kubernetes. Instead, only explicitly set values are retained in etcd.

On the other hand, Argo CD performs a comparison between the live state of the resource (as seen in etcd) and the desired state defined by Helm charts. Since the stackable Helm templates for CRDs explicitly include a few fields with their default values, discrepancies arise during the comparison:

Helm-generated manifests: These contain explicitly defined default values.
Kubernetes live state: Does not include these default values, as they are not persisted in etcd.
This mismatch leads to Argo CD reporting a difference and blocking synchronization, even though the live state is functionally identical to the desired state due to Kubernetes' dynamic application of defaults.

This issue is unlikely to be resolved in Argo CD because it would require the tool to know all default values for every Kubernetes object, including CRDs. Handling this would mean Argo CD needs to fetch and interpret OpenAPI schemas for every resource and Kubernetes version, including custom CRDs.

That's why I propose to remove the some default values from stackable CRDs, it is a simple and efficient short-term solution.

[fjammes]

In addition, I have created a tiny kube-derive poc, do you think it is possible to configure it not to print fields with default values? https://github.com/k8s-school/kube-derive-poc