Migration einer eigenständigen Resource Group in eine Organisation

Diese Anleitung führt durch die Migration einer bestehenden, eigenständigen Resource Group in eine neue Organisation.

Da eine einheitliche Governance voraussetzt, dass alle Mitglieder einer Resource Group auch Mitglieder der Organisation sind, kann eine Migration ins Stocken geraten, wenn die Resource Group externe Benutzer enthält. Dieses Tutorial zeigt, wie ein solcher Konflikt über die API gelöst werden kann.

Szenarioübersicht

Du bist Organization Admin. Du hast eine bestehende Resource Group (resourceGroupId: 42), die in deine Organisation verschoben werden soll. Zwei Benutzer dieser Resource Group ([email protected] und [email protected]) sind jedoch noch nicht Teil der Organisation. Alice soll erhalten bleiben, aber es ist in Ordnung, wenn Bob während der Verschiebung aus der Resource Group entfernt wird.

Schritt 1: Organization ID ermitteln

Bevor die Resource Group migriert werden kann, muss die Ziel-organizationId bekannt sein. Dazu wird eine Liste aller Organisationen abgerufen, denen man angehört.

• Endpunkt: GET /organizations
• Aktion: Finde die Zielorganisation im Antwort-Array und kopiere ihre id (z. B. 123e4567-e89b-12d3-a456-426614174000).

Schritt 2: Migrationsversuch (und Fehlschlag)

Wir versuchen, die Resource Group zu migrieren. Da wir auf Nummer sicher gehen wollen, lassen wir das force-Flag weg (Standardwert false).

• Endpunkt: POST /resource-groups/42/migrate

• Payload:

  {
    "organizationId": "123e4567-e89b-12d3-a456-426614174000"
  }

• Ergebnis: Die API lehnt die Anfrage ab, da Alice und Bob nicht Mitglieder der Organisation sind. Es wird ein 400 Bad Request mit folgendem Fehlerdetail zurückgegeben:

  Cannot migrate team to organization because the following team members are not members of the new organization: [email protected], [email protected]. Either add the members to the organization before migrating, or use the force option to remove them from the team and proceed with the migration.

Schritt 3: Erforderliches Mitglied hinzufügen

Da Alice in der Resource Group bleiben soll, muss sie zunächst in die übergeordnete Organisation eingeladen werden.

• Endpunkt: POST /organizations/123e4567-e89b-12d3-a456-426614174000/members
• Payload:

  {
    "email": "[email protected]",
    "role": "member"
  }

• Ergebnis: Alice ist nun offiziell Teil der Organisation.

Schritt 4: Migration erzwingen

Wir wollen Bob nicht zur Organisation hinzufügen und akzeptieren, dass er nach der Migration keinen Zugriff mehr auf die Resource Group hat. Wir rufen den Migrationsendpunkt erneut auf, diesmal mit explizit gesetztem force: true.

• Endpunkt: POST /resource-groups/42/migrate
• Payload:

  {
    "organizationId": "123e4567-e89b-12d3-a456-426614174000",
    "force": true
  }

• Ergebnis: Erfolg! HTTP 200 OK. Die Resource Group wird in die Organisation verschoben. Bob wird automatisch aus der Resource Group entfernt, während Alice Mitglied der Resource Group bleibt.

Schritt 5: Migration überprüfen

Abschließend prüfen wir die Liste der Resource Groups unserer Organisation, um sicherzustellen, dass die bestehende Resource Group nun ordnungsgemäß in unsere Governance-Struktur eingegliedert ist.

• Endpunkt: GET /organizations/123e4567-e89b-12d3-a456-426614174000/resource-groups
• Ergebnis: Das Antwort-Array enthält nun die neu migrierte Resource Group.