Uploaded image for project: 'OCMUI - OpenShift Cluster Manager UI'
  1. OCMUI - OpenShift Cluster Manager UI
  2. OCMUI-136

[ROSA] Enable cluster owner to initiate cluster transfer

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • Core UI
    • Enable cluster owner to initiate cluster transfer
    • Product / Portfolio Work
    • True
    • Hide

      The backend issue OCM-15247 caused the undesired behavior in UI OCMUI-3340 . This currently blocks the original acceptance criteria

      Show
      The backend issue OCM-15247 caused the undesired behavior in UI OCMUI-3340 . This currently blocks the original acceptance criteria
    • False
    • In Progress
    • XCMSTRAT-293 - Cluster ownership transfer process improvements - M1
    • 0% To Do, 0% In Progress, 100% Done
    • Released Jun 9, 2025

      Update:

      This feature is being resurrected from plans done several years ago.  Current teams from OCMUI, AMS, and CS are meeting to discuss plans moving forward.

      Currently, we have the following notes:

      1) OCMUI has created an MVP to test the current state of the apis.  Several issues have been determined:

          a) API does not allow cluster to be re-transfer after transfer canceled or completed  FIXED

         b) No indicator on the cluster object (in state or subscription state) that indicated a transfer in progress

      2)  From a backend perspective, we are only supporting ROSA classic for now (Milestone 1).  The backend has to create a new process to notify users of the transfer.  The API coding has started and is expected to be complete within 3 weeks

      3) CS team has been notified about possible updates for the Cluster object to identify a transfer is in place.  There is also a need to decide if the cluster should be locked from changes while in the transfer state.

      Detail

      1) User initiates a transfer from the UI.  Needs to provide recipient username for in-org transfer, and needs to have account ID and organization for out of org transfer. All 3 fields are now required for all transfers.

      2) A transfer object is created using the cluster_transfer api endpoint on account management.

      3) From this point, owner can cancel the transfer or the recipient can accept or declined the transfer

      4) The UI will need a way for recipient to accept/decline the transfer (OCMUI-3057)

      5) Cluster must be in ready state to initiate a transfer for ROSA clusters.  Future milestones may have slightly different requirement, for example, OCP clusters can also be transferred in a disconnected state.  These items will be addressed in those epics.

      User Story

      As a customer, I want to see options to upgrade or take action on my unsupported cluster or trial. If I signed up through a personal account instead of my organization, I should be prompted to transfer cluster ownership to my org admin or take action around my subscription. 

      As a customer, I want the option to transfer my ROSA cluster to another user in my org and in another RH org.

      Acceptance Criteria

      • Milestone 1 will be for ROSA classic clusters only
      • Users should be able to transfer a cluster from  the:
        • OCM cluster list
        • OCM cluster details (overview and access tab)
        • OCP cluster settings (already done as part of CONSOLE-2280) 
      • If no subscriptions exist, we should make it easy to transfer cluster ownership through the UI without necessarily retrieving the pull secret. Offer Account ID or Email as alternative option and provide a way for users to view, edit, cancel throughout the transfer process. 
      • For OSD, this flow should be available as well, however we should block transfers when no support is available at the destination account (instead of warning in the case of OCP) 

      Background

      Currently are ~2000 unclassified clusters. Having clusters in an unclassified state means that Red Hat does not understand what Custom Global Customer Name (GCN) the cluster is associated with. This limits Red Hat’s ability to engage with the owner of the cluster in a meaningful way which decreases chances of revenue generation, retention, and customer success. There are several scenarios by which these unclassified clusters can occur. One key scenario is the group that is creating a cluster outside of their existing org and never taking action to transfer to the right place where RH would have visibility to engage. See slides for details: Unclassified Clusters Overview 

      Design

      Updates:

      1) Cluster transfer can only be initiated from ready state, however, an archived cluster can be accepted if already in transfer state

      2)  Expiration of transfer will change from 5 days to 15 days

       

      Transfer cluster ownership - Auth token (outdated)

      ^If needed. Pull secret could also work for this option but sharing your pull secret (current implementation) has security concerns(outdated)

      Transfer cluster ownership - Approval flow (outdated)

      Latest designs:
      Current Mockups (April 2025)

      See https://issues.redhat.com/browse/HPUX-511 for latest design updates

      MVP was created and attached.  Please take a look for the transfer initiation.

       

      cc crobson@redhat.comkhatchousmordech@redhat.com, dramakri@redhat.com, kdoberstrhn-engineering-gsheremedayle.parker, rhn-engineering-abhgupta 

              zherman Zac Herman
              chart@redhat.com Colleen Hart
              Jayakrishnan Mekkattillam Jayakrishnan Mekkattillam
              HAC
              Votes:
              0 Vote for this issue
              Watchers:
              17 Start watching this issue

                Created:
                Updated:
                Resolved: