Bug 2081700

Summary:	Deployment of provider addon is in failed state for a short amount of time before it turns to ready
Product:	[Red Hat Storage] Red Hat OpenShift Data Foundation	Reporter:	Filip Balák <fbalak>
Component:	odf-managed-service	Assignee:	Akshay Khanna <akkhanna>
Status:	CLOSED DUPLICATE	QA Contact:	Neha Berry <nberry>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.10	CC:	aeyal, akkhanna, dahorak, ocs-bugs, odf-bz-bot, sabose
Target Milestone:	---	Keywords:	AutomationBlocker
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-06-27 10:52:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Filip Balák 2022-05-04 12:06:47 UTC

Description of problem:
When addon ocs-provider-qe was being deployed, it went to failed state and after a while it changed to ready state.

Version-Release number of selected component (if applicable):
ocs-operator.v4.10.0
ocs-osd-deployer.v2.0.1
odf-operator.v4.10.0
ocp 4.10.11

How reproducible:
3/?
It happened recently on multiple occasions.

Steps to Reproduce:
1. Deploy provider addon with 3 availability zones set
2. Check addon status

Actual results:
The addon gets into failed state before it successfully finishes deployment with error in UI: 'ocs-osd-deployer' : 'InstallCheckFailed'
The status is also visible with command: rosa list addons -c <cluster-name>

Expected results:
The cluster should be in installed phase without turning into failed.

Additional info:

Comment 3 Akshay Khanna 2022-05-17 07:11:36 UTC

I've tried to reproduce this twice, and it didn't get into the failed state even once. 

I used these versions:

ocs-operator.v4.10.0
ocs-osd-deployer.v2.0.1
odf-operator.v4.10.0
ocp 4.10.11

Comment 4 Filip Balák 2022-06-27 10:52:50 UTC


*** This bug has been marked as a duplicate of bug 2076207 ***