Idea: CLI Command to Unregister a Cluster from Cloud

[jcasimir]

miren server register is a one-way door. There's no inverse command to detach a self-hosted cluster from a miren.cloud organization, either to retire the cluster cleanly or to move it to a different org. Today this requires manual file manipulation on the server and leaves an unreachable orphan entry on the miren.cloud side that the CLI cannot clean up at all.

Scenario

I have a Miren cluster that was originally registered under one miren.cloud org. I needed to move it to a different org. There is no documented path for this, and sudo miren server register -n <new-name> errors with cluster already registered as <old-name> because registration state already exists on disk.

Workaround

To move the cluster between orgs I did the following:

1. Stop and back up /var/lib/miren/server/.
2. Manually rename four files aside so the server would no longer consider itself registered:
   • registration.json
   • registration.json.bak
   • service-account.key
   • oidc-signing.key
3. After renaming, sudo miren server register status immediately reports No cluster registration found (file-based check — no service action needed for the check itself).
4. miren login against the new org, then sudo miren server register -n <new-name>.
5. sudo systemctl restart miren.service for the new registration to take effect at runtime.

This worked, but:

• It's undocumented, so users have to either guess at which files to move (ca.crt/ca.key and api.crt/api.key must not be touched, since they secure CLI-to-cluster cert auth and are unrelated to cloud registration — this isn't obvious) or read the source.
• The miren.cloud side now has an orphan cluster entry under the old org. The CLI exposes no way to remove it; it has to be deleted manually through the miren.cloud web UI by someone with access to the old org. If the user moving the cluster doesn't have access to the old org they cannot finish the cleanup themselves at all.

Proposal

Add an inverse to miren server register. Strawman:

miren server unregister [--force]

Behavior, roughly mirroring register in reverse:

1. Notify miren.cloud to remove the cluster entry from the org (revoke the service account, delete the cluster row).
2. Remove the local registration files in /var/lib/miren/server/ (the same set listed above), leaving the CLI-to-cluster TLS material (ca.*, api.*) intact.
3. Either hot-reload registration state in the running server, or require a restart and say so explicitly.

Open Questions

These feel like they need a maintainer call before any PR work:

1. Naming. unregister (mirrors register) vs deregister? Subcommand of server or top-level?
2. Live apps and routes. Should unregister be allowed while apps are running, or should it require the cluster be drained first? If allowed, what guarantees does the user get about app continuity?
3. Cloud-side vs local atomicity. What's the right behavior when one half succeeds and the other fails? E.g., cloud-side delete succeeds but the local file cleanup errors — does the cluster end up in a worse state than before? Should there be a --local-only escape hatch for the case where the cloud side is already gone (orphan recovery)?
4. Org-side orphan recovery. Independent of unregister: should there be a separate command for "I'm an org admin, delete this orphan cluster row" — usable when the cluster itself is dead and unreachable? This is the case I can't fix today, even after the local cluster was successfully re-registered elsewhere.
5. Re-registration without re-install. If someone unregisters and then registers again against a new org, should the cluster ID be regenerated, or could/should it be preserved across re-registration? (Today, manually clearing the four files appears to result in a fresh cluster ID and service account on next register, which seems right — but worth confirming that's the intended semantic.)
6. Permissions. Today sudo miren server register requires root because it writes to /var/lib/miren/server/. Unregister presumably does too. Is there an authorization check on the cloud side beyond "you have a cloud identity" — e.g., must the caller's identity be an admin of the org the cluster is registered in?