Bug 1825830

Summary: [NooBaa] BucketClass status should be updated according to the BackingStores it uses
Product: [Red Hat Storage] Red Hat OpenShift Container Storage Reporter: Ben Eli <belimele>
Component: Multi-Cloud Object GatewayAssignee: Danny <dzaken>
Status: CLOSED ERRATA QA Contact: Ben Eli <belimele>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.3CC: dzaken, ebenahar, etamir, nbecker, ocs-bugs
Target Milestone: ---Keywords: AutomationBackLog
Target Release: OCS 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 4.4.0-413 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-04 12:54:39 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 Ben Eli 2020-04-20 10:54:51 UTC
Description of problem (please be detailed as possible and provide log
snippests):
When creating new OBCs via the Kube control plane (S3 works fine) - OBCs are being rejected -

>message: NooBaa BackingStore "noobaa-default-backing-store" is in rejected phase
>reason: RejectedBackingStore

However, the backingstore is okay...

    message: BackingStorePhaseReady
    reason: 'Backing store mode: OPTIMAL'
    status: "True"
    type: Upgradeable
  mode:
    modeCode: OPTIMAL
    timeStamp: 2020-04-16 12:13:56.814669268 +0000 UTC m=+2.078978622
  phase: Ready

After talking to Danny from NooBaa, apparently there's a bug where a bucketclass will not automatically reconcile if its backingstore was in a rejected state in the initial check.


Must-gather can be supplied upon request

Version of all relevant components (if applicable):
OCP 4.3.0-0.nightly-2020-04-16-053416
OCS v4.3.0-407.ci

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes. It caused NooBaa to not work on a brand new cluster.

Is there any workaround available to the best of your knowledge?
Not that I know

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

Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
No

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


Steps to Reproduce:
1. Create a backingstore that'll be rejected (I created one with a target bucket that doesn't exist)
2. Create a bucketclass that uses the backingstore - the bucketclass is instantly rejected
3. Fix the backingstore (I created a target bucket with a name that fits the name I used in the backingstore creation)
4. The bucketclass remains rejected


Actual results:
The bucketclass is rejected

Expected results:
The bucketclass reconciles and its state changes to ready

Comment 12 errata-xmlrpc 2020-06-04 12:54: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, 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/RHBA-2020:2393