-
Bug
-
Resolution: Done
-
Normal
-
None
-
4.11.z
-
None
-
Moderate
-
No
-
False
-
This is a clone of issue OCPBUGS-11699. The following is the description of the original issue:
—
Description of problem:
Automatic upgrade of MetalLB operator to the new 4.11 CSV version fails with: error validating existing CRs against new CRD's schema for "addresspools.metallb.io": error listing resources in GroupVersionResource schema.GroupVersionResource{Group:"metallb.io", Version:"v1alpha1", Resource:"addresspools"}: conversion webhook for metallb.io/v1beta1, Kind=AddressPool failed: no kind "AddressPool" is registered for version "metallb.io/v1alpha1" in scheme "/metallb/internal/k8s/k8s.go:59" There doesn't seem to be any alternative apart from removing the operator and installing it again. Looks like the code mentioned in the error is missing the v1alpha1 apiVersion variables? In my case the addressPool was already configured as: - apiVersion: metallb.io/v1beta1 kind: AddressPool
Version-Release number of selected component (if applicable):
metallb-operator.4.11.0-202303240327 MetalLB Operator 4.11.0-202303240327 Replacing metallb-operator.4.11.0-202303311828 MetalLB Operator 4.11.0-202303311828 metallb-operator.4.11.0-202303240327 Pending
How reproducible:
Everytime
Steps to Reproduce:
1. Let the metallb-operator upgrade to the new version on the channel. 2. (not sure) Have the old addressPools configured
Actual results:
Upgrade fails and operator gets stuck in upgrading stack and may lead to fully nonfunctional
Expected results:
Seemless upgrades of the operator
- clones
-
OCPBUGS-11699 MetalLB operator 4.11 update fails with addressPool apiVersion conversion
- Closed
- is blocked by
-
OCPBUGS-11699 MetalLB operator 4.11 update fails with addressPool apiVersion conversion
- Closed
- links to