Bug 2242854

Summary:	Noobaa should fallback to a pv-pool default BS when CCO is not providing credentials
Product:	[Red Hat Storage] Red Hat OpenShift Data Foundation	Reporter:	Danny <dzaken>
Component:	Multi-Cloud Object Gateway	Assignee:	Shira Dymnik <sdymnik>
Status:	CLOSED ERRATA	QA Contact:	Uday kurundwade <ukurundw>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.14	CC:	edonnell, odf-bz-bot
Target Milestone:	---
Target Release:	ODF 4.14.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	4.14.0-151	Doc Type:	Bug Fix
Doc Text:	.NooBaa now falls back to using a backing store with type pv-pool when credentials are not provided in the limited time When the cloud credentials operator cannot or fails to provide a secret after the cloud credential request was created, for example, before installing NooBaa the cloud credential operator mode was set to manual mode and no additional necessary actions were done. The provided secret includes the credentials needed for creating the target bucket for the default backing store. This means, the default backing store was not created and Noobaa was stuck in phase Configuring. With this fix, if the cloud credential request was sent and we could not get the secret by the limited time that was defined (10 minutes), then NooBaa would fall back to using a backing store with type pv-pool. This means the system should be in status Ready and the default backing store should be with type pv-pool.	Story Points:	---
Clone Of:
Clones:	2242880 (view as bug list)		Environment:
Last Closed:	2023-11-08 18:55:10 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:
Bug Depends On:
Bug Blocks:	2242880, 2244409

Description Danny 2023-10-09 11:55:39 UTC

Description of problem (please be detailed as possible and provide log
snippets):

when the cloud credentials operator can't or fails to provide credentials (e.g.: the CCO is in manual mode), the creation of noobaa is stuck, waiting for the CCO to create the credentials secret


Version of all relevant components (if applicable):


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


Is there any workaround available to the best of your knowledge?
yes. creating the default BS manually


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


Can this issue reproducible?
yes

Can this issue reproduce from the UI?


If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1. install ODF in manual mode
2.
3.


Actual results:
noobaa installation is stuck pending on the credentials secret

Expected results:
noobaa should fallback to a pv pool BS after a timeout.
A proper alert should be generated, notifying the user of the failure to create a default BS of the intended type, and the creation of a pv-pool BS


Additional info:

Comment 7 errata-xmlrpc 2023-11-08 18:55:10 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: Red Hat OpenShift Data Foundation 4.14.0 security, enhancement & bug fix 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-2023:6832