fix: align release-1.1 addon KubeBlocks version constraints - #3238
Conversation
Several release-1.1 addon charts render custom-resource fields that are unavailable at their declared KubeBlocks version floor. - Require KubeBlocks >1.0.2 for 15 charts that render exclusive replica roles. - Require KubeBlocks >=1.0.2 for Elasticsearch pod upgrade policy support. - Keep MySQL unchanged because it already declares the correct >1.0.2 floor. Validated all 39 installable release-1.1 charts with Helm lint and rendering, then compared the rendered custom resources against the KubeBlocks v1.0.1, v1.0.2, v1.0.3-beta.0, and release-1.1 structural CRD schemas. The release-1.0 snapshot has the same API requirements for every common chart; FalkorDB is not present on that branch.
|
/cherry-pick release-1.0 |
|
🤖 says: Error cherry-picking. |
|
🤖 says: |
What changed
>1.0.2for 15 release-1.1 addon charts that render exclusive replica roles.>=1.0.2for Elasticsearch because it renderspodUpgradePolicy.>1.0.2floor.Why
These release-1.1 charts declared a KubeBlocks version floor that could not accept their rendered custom resources. This allowed incompatible addons to be selected on KubeBlocks 1.0.0 through 1.0.2.
The constraints are derived from full rendered-manifest comparison against structural CRD schemas, rather than from a checker hardcoded to individual API fields.
Release-1.0 backport
The remote
release-1.0snapshot renders the same incompatible fields for every chart common to this PR, so this PR is labeledpick-1.0.FalkorDB exists on
release-1.1but not onrelease-1.0. If the automatic cherry-pick reports a modify/delete conflict, omitaddons/falkordb/Chart.yaml; the other 15 metadata changes apply torelease-1.0.Validation
release-1.1addon charts.v1.0.1,v1.0.2,v1.0.3-beta.0, andrelease-1.1structural CRD schemas.v1.0.1and passesv1.0.2.v1.0.2and passv1.0.3-beta.0; MySQL already had the correct floor.release-1.0snapshot and confirmed the same schema requirements for its common charts.git diff --check.Chart.yamlfiles.