Bug 2102782 - topolvm-controller get into CrashLoopBackOff few minutes after install
Summary: topolvm-controller get into CrashLoopBackOff few minutes after install
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 4.11
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.11.0
Assignee: Jan Safranek
QA Contact: Wei Duan
URL:
Whiteboard:
Depends On: 2101343
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-30 16:10 UTC by OpenShift BugZilla Robot
Modified: 2022-08-10 11:20 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-10 11:19:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift csi-external-provisioner pull 53 0 None open [release-4.11] Bug 2102782: UPSTREAM: 2101343: fix: changed the csistoragecapacity check namespace 2022-06-30 16:10:55 UTC
Red Hat Product Errata RHSA-2022:5069 0 None None None 2022-08-10 11:20:05 UTC

Description OpenShift BugZilla Robot 2022-06-30 16:10:36 UTC
+++ This bug was initially created as a clone of Bug #2101343 +++

This bug was initially created as a copy of Bug #2101139

I am copying this bug because: 

The fix is in the external-provisioner sidecar.


Description of problem (please be detailed as possible and provide log
snippests):
When installing lvmcluster the following occurs:
oc get pods
NAME                                               READY   STATUS             RESTARTS      AGE
lvm-operator-controller-manager-666d94dfd6-l2w26   3/3     Running            0             12m
topolvm-controller-7f54b85768-4czjk                4/5     CrashLoopBackOff   2 (19s ago)   4m36s
topolvm-node-bjq9n                                 0/4     Init:0/1           0             4m36s
vg-manager-l4q2v                                   1/1     Running            0             4m36s




Version of all relevant components (if applicable):
odf-operator quay.io/rhceph-dev/ocs-registry:4.11.0-103

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Can't install lvmcluster

Is there any workaround available to the best of your knowledge?
No

Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
1

Can this issue reproducible?
2/2

Can this issue reproduce from the UI?
NR

If this is a regression, please provide more details to justify this:
Cluster could be installed and now not

Steps to Reproduce:
1. install SNO
2. Create namespace openshift-storage. Create operator group and sub for lvm
3. Install LVM cluster


Actual results:
(381venv) [srozen@srozen-lap 4.11]$ oc get pods
NAME                                               READY   STATUS             RESTARTS      AGE
lvm-operator-controller-manager-666d94dfd6-l2w26   3/3     Running            0             12m
topolvm-controller-7f54b85768-4czjk                4/5     CrashLoopBackOff   2 (19s ago)   4m36s
topolvm-node-bjq9n                                 0/4     Init:0/1           0             4m36s
vg-manager-l4q2v                                   1/1     Running            0             4m36s


Expected results:
All pod should be in running state.





RCA:
This is a bug introduced in the recently released external-provisioner v3.2.0. The OCP 4.11 CSI sidecar images were updated last week after which the LVMO build started to fail.


Upstream Issue: https://github.com/kubernetes-csi/external-provisioner/issues/752

Upstream Fix: https://github.com/kubernetes-csi/external-provisioner/pull/753

--- Additional comment from nibalach on 2022-06-27 11:10:25 UTC ---

The upstream PR and its backport have been merged.

https://github.com/kubernetes-csi/external-provisioner/pull/753
https://github.com/kubernetes-csi/external-provisioner/pull/754

Comment 2 Wei Duan 2022-07-04 06:01:34 UTC
According to https://bugzilla.redhat.com/show_bug.cgi?id=2101343#c5, I think it is enough for the verificarion for the default namespace issue in csi-external-provisioner image, will mark it as VERIFIED. Feel free to re-open or raise another BZ if it doesn't work on LVMO-4.11/4.12

Comment 4 errata-xmlrpc 2022-08-10 11:19:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5069


Note You need to log in before you can comment on or make changes to this bug.