Allow noobaa on the client side to be deleted

[ezio-auditore]

The noobaa client is not getting deleted because the Cleanup Policy is not being set and holding un-installation of ocs-client. This patch fixes the above
Changes incude

• Add Cleanup policy to noobaa

• change noobaa-remote to noobaa
  the name of the noobaa system needs to be noobaa as pointed out below

  • https://github.com/noobaa/noobaa-operator/blob/0ae4f766c5f295aaf61642c93aa7c569c3d0edfb/pkg/system/phase1_verifying.go#L86
  • https://github.com/noobaa/noobaa-operator/blob/0ae4f766c5f295aaf61642c93aa7c569c3d0edfb/pkg/options/options.go#L50

• edit noobaa-remote-join-secret mgmt_addr to include the https scheme and port
  the mgmt_addr created via noobaa-remote-join-secret needs to have an https scheme and port other it will not be consumed by noobaa-core for connecting to the remote noobaa system

[ezio-auditore]

/assign @leelavg

[leelavg]

From the description I can understand the cleanup policy but not the other two points, could you pls expand on it? thanks.

[ezio-auditore]

From the description I can understand the cleanup policy but not the other two points, could you pls expand on it? thanks.

@leelavg
Updated in description

[leelavg]

@leelavg, Updated in description

• thanks, isn't this scheme going to restrict client-cluster to only connect to a single noobaa provider? or we can manage it later since noobaa is namespaced resource, will this be inhibiting any future use cases that a client cluster be onboarded to multiple providers

[leelavg]

as it's https I'm assuming server & client speaks over TLS, so what certs are being used here?

[ezio-auditore]

The above is the secret from which noobaa-operator on the client side will connect to the provider side noobaa management address. The certs are being handled on the noobaa-core if I am not wrong.

[leelavg]

When it connects, for the simplest case client verifies that it is speaking to correct server isn't it? For that usually certs are presented, IOW did you check the feature is working as expected w/o providing certs explicitly?

[ezio-auditore]

Yes it connects to the provider noobaa with ready status. Below is from a client cluster.

oc get noobaa noobaa -oyaml
apiVersion: noobaa.io/v1alpha1
kind: NooBaa
metadata:
  annotations:
    remote-client-noobaa: "true"
  creationTimestamp: "2024-10-14T12:02:25Z"
  finalizers:
  - noobaa.io/graceful_finalizer
  generation: 2
  labels:
    app: noobaa
  name: noobaa
  namespace: openshift-storage
  ownerReferences:
  - apiVersion: ocs.openshift.io/v1alpha1
    kind: StorageClient
    name: ocs-storage-client
    uid: 1b60d41c-0d62-454e-b04c-e7c59fb79ea2
  resourceVersion: "8113000"
  uid: 4b1bf9b4-e83d-4620-9fdc-8f8b72dbbb5c
spec:
  autoscaler: {}
  bucketLogging: {}
  cleanupPolicy:
    allowNoobaaDeletion: true
  joinSecret:
    name: noobaa-remote-join-secret
    namespace: openshift-storage
  loadBalancerSourceSubnets: {}
  security:
    kms: {}
status:
  accounts:
    admin:
      secretRef: {}
  actualImage: registry.redhat.io/odf4/mcg-core-rhel9@sha256:2a7effe96f6419a7740ba0e3dbd9e1372f226339b70f9d204cbdd0a643fb6af4
  conditions:
  - lastHeartbeatTime: "2024-10-15T09:52:53Z"
    lastTransitionTime: "2024-10-15T09:52:53Z"
    message: noobaa operator completed reconcile - system is ready
    reason: SystemPhaseReady
    status: "True"
    type: Available
  - lastHeartbeatTime: "2024-10-15T09:52:53Z"
    lastTransitionTime: "2024-10-15T09:52:53Z"
    message: noobaa operator completed reconcile - system is ready
    reason: SystemPhaseReady
    status: "False"
    type: Progressing
  - lastHeartbeatTime: "2024-10-15T09:52:53Z"
    lastTransitionTime: "2024-10-14T12:02:25Z"
    message: noobaa operator completed reconcile - system is ready
    reason: SystemPhaseReady
    status: "False"
    type: Degraded
  - lastHeartbeatTime: "2024-10-15T09:52:53Z"
    lastTransitionTime: "2024-10-15T09:52:53Z"
    message: noobaa operator completed reconcile - system is ready
    reason: SystemPhaseReady
    status: "True"
    type: Upgradeable
  observedGeneration: 2
  phase: Ready
  readme: "\n\n\tWelcome to NooBaa!\n\t-----------------\n\tNooBaa Core Version:     master-20240520\n\tNooBaa
    Operator Version: 5.18.0\n\n\tLets get started:\n\n\tTest S3 client:\n\n\t\tkubectl
    port-forward -n openshift-storage service/s3 10443:443 &\n\t\tNOOBAA_ACCESS_KEY=$(kubectl
    get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')\n\t\tNOOBAA_SECRET_KEY=$(kubectl
    get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')\n\t\talias
    s3='AWS_ACCESS_KEY_ID=$NOOBAA_ACCESS_KEY AWS_SECRET_ACCESS_KEY=$NOOBAA_SECRET_KEY
    aws --endpoint https://localhost:10443 --no-verify-ssl s3'\n\t\ts3 ls\n\n"
  services:
    serviceMgmt: {}
    serviceS3:
      externalDNS:
      - https://s3-openshift-storage.apps.kmajumder-client.ocs.syseng.devcluster.openshift.com:443
      - https://a027bf7c85e6b4807820eb7f881ef92b-1498412627.ap-south-1.elb.amazonaws.com:443
      internalDNS:
      - https://s3.openshift-storage.svc:443
      internalIP:
      - https://172.30.235.24:443
    serviceSts:
      externalDNS:
      - https://sts-openshift-storage.apps.kmajumder-client.ocs.syseng.devcluster.openshift.com:443
      - https://ab57cf70e53734f03adc06ecfc8ec446-26135574.ap-south-1.elb.amazonaws.com:443
      internalDNS:
      - https://sts.openshift-storage.svc:443
      internalIP:
      - https://172.30.90.229:443
    serviceSyslog: {}
    ```

[leelavg]

Below is from a client cluster.

• ack, based on naming ...apps.kmajumder-client.ocs... I'm assuming this is not local client, thanks.

[leelavg]

as the remote noobaa system name which is noobaa

• that or the name should be noobaa irrespective of remote or local, pointed code is signifying the latter, isn't it?

[ezio-auditore]

as the remote noobaa system name which is noobaa

• that or the name should be noobaa irrespective of remote or local, pointed code is signifying the latter, isn't it?

Yes true, found it here -> https://github.com/noobaa/noobaa-operator/blob/0ae4f766c5f295aaf61642c93aa7c569c3d0edfb/pkg/options/options.go#L50

[ezio-auditore]

@leelavg, Updated in description

• thanks, isn't this scheme going to restrict client-cluster to only connect to a single noobaa provider? or we can manage it later since noobaa is namespaced resource, will this be inhibiting any future use cases that a client cluster be onboarded to multiple providers

I don't see why it can't be done as you mentioned noobaa being a namespaced resource. One noobaa client per namespace. We might have to update noobaa-operator to accept multiple noobaa client CRs connected to providers.

[leelavg]

/lgtm

need approval vote from @nb-ohad though.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ezio-auditore, leelavg
Once this PR has been reviewed and has the lgtm label, please assign travisn for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-merge-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.