cloud credentials secret is not ready marked as a TemporaryError but it is not always temporary

[gregsheremeta]

Environment info

• NooBaa Operator Version: noobaa-operator:5.11.0
• Platform: OpenShift 4.12 - ROSA HCP (hosted control plane)

noobaa-operator incorrectly classifies the failure to come up due to cloud credentials secret "noobaa-aws-cloud-creds-secret" is not ready as a TemporaryError. It seems as though noobaa assumes that cloud-credential-operator will always run on all flavors of OpenShift, and that is not the case [*]. In my case, I suspect noobaa isn't supported on ROSA HCP, and so TemporaryError is misleading.

Actual behavior

oc get noobaa -o yaml

  - lastHeartbeatTime: "2023-06-28T20:56:35Z"
    lastTransitionTime: "2023-06-28T20:56:35Z"
    message: cloud credentials secret "noobaa-aws-cloud-creds-secret" is not ready
      yet
    reason: TemporaryError
    status: "False"
    type: Available

Expected behavior

If noobaa hard requires cloud-credentials-operator to be running such that CredentialsRequests are reconciled, the reason should be something more like UnsupportedPlatform.

Steps to reproduce

noobaa install on a freshly installed ROSA HCP cluster.

Other

Is there a way I can install noobaa-operator without using backing S3 storage? Can I specify that at install time?

[*]
ref1: https://github.com/openshift/cloud-credential-operator#3-manual-credentials-management
ref2: https://github.com/openshift/cloud-credential-operator#4-short-lived-tokens
ref3: https://docs.openshift.com/container-platform/4.13/authentication/managing_cloud_provider_credentials/cco-mode-sts.html

CredentialRequests do not work on OCP STS, ROSA STS, and ROSA HCP clusters.

[nimrod-becker]

@dannyzaken
We can override the default after deployment.
Do we still have the option to set it during deployment?

[dannyzaken]

Hi @gregsheremeta

In 5.11 you can specify a default backingstore spec in NooBaa CR. You can provide a backingstore spec of PVPool for example, that will create local pvs as the default backingstore. see here:

noobaa-operator/pkg/apis/noobaa/v1alpha1/noobaa_types.go

Lines 183 to 184 in 9e4f8e3

	// +optional
	DefaultBackingStoreSpec *BackingStoreSpec `json:"defaultBackingStoreSpec,omitempty"`

Notice that this option will be deprecated in 5.13 and up. in 5.13 there is a boolean flag in noobaa CR manualDefaultBackingStore, to disable the automatic creation of a default backingstore. NooBaa still needs a default backingstore to operate correctly. When using this flag, the user has to manually create a backingstore and reference it in the default-bucket-class