You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 13, 2024. It is now read-only.
#139 changed the behavior of az capi management delete actually to delete the management cluster after confirmation, as we agreed this is the expected behavior. This new behavior could be further improved by showing any existing workload clusters before asking for confirmation:
Please note that "my-cluster" is managing workload clusters:
NAMESPACE NAME PHASE AGE VERSION
default default-20520 Provisioned 22m11s
default default-32106 Provisioned 2m28s
default default-70206 Provisioning 45s
Deleting the management cluster will leave these workload clusters in their
current configuration, without a way to manage them.
But this would probably have to be implemented as a "best effort" strategy, since it's possible the management cluster has failed or become inaccessible (hence the user is deleting it).
#139 changed the behavior of
az capi management delete
actually to delete the management cluster after confirmation, as we agreed this is the expected behavior. This new behavior could be further improved by showing any existing workload clusters before asking for confirmation:But this would probably have to be implemented as a "best effort" strategy, since it's possible the management cluster has failed or become inaccessible (hence the user is deleting it).
See https://github.com/Azure/azure-capi-cli-extension/pull/139/files#r891383438 for more context.
The text was updated successfully, but these errors were encountered: