Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-11699

MetalLB operator 4.11 update fails with addressPool apiVersion conversion

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Normal Normal
    • 4.12.0
    • 4.11.z
    • Networking / Metal LB
    • None
    • Moderate
    • No
    • CNF Network Sprint 235
    • 1
    • False
    • Hide

      None

      Show
      None

      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
      

              fpaoline@redhat.com Federico Paolinelli
              rhn-support-andcosta Andre Costa
              Arti Sood Arti Sood
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: