What you would like to be added?
Problem
Currently, helm upgrade does not upgrade CustomResourceDefinitions (CRDs) for the Grove operator.
This causes version mismatches between the operator and installed CRDs, which can lead to:
- Broken upgrades
- Runtime errors
- Users running with outdated CRD schemas
- Subtle bugs when new fields / validations are added
By default, Helm does not manage CRD upgrades, and our current release pipeline does not compensate for this behavior.
Impact
- Users upgrading the operator may still run old CRDs
- New operator versions may rely on CRD fields that don’t exist
- Hard-to-debug production issues
- Inconsistent cluster state across upgrades
Expected Behavior
CRDs should always be upgraded as part of:
- Operator installation
- Operator upgrade
Why is this needed?
Proposed Solution
Add a dedicated step to the installation flow that ensures CRDs are applied/upgraded before or alongside the operator:
Add a Kubernetes Job or Helm hook to kubectl apply -f crds/
Wire this into:
- Helm install
- Helm upgrade
Acceptance Criteria
- CRDs are upgraded automatically on helm upgrade
- No manual steps required from users
- Operator can safely rely on latest CRD schema after upgrade
What you would like to be added?
Problem
Currently, helm upgrade does not upgrade CustomResourceDefinitions (CRDs) for the Grove operator.
This causes version mismatches between the operator and installed CRDs, which can lead to:
By default, Helm does not manage CRD upgrades, and our current release pipeline does not compensate for this behavior.
Impact
Expected Behavior
CRDs should always be upgraded as part of:
Why is this needed?
Proposed Solution
Add a dedicated step to the installation flow that ensures CRDs are applied/upgraded before or alongside the operator:
Add a Kubernetes Job or Helm hook to kubectl apply -f crds/
Wire this into:
Acceptance Criteria