Removing finalizers from mgmt cluster breaks the UI

rancher / dashboard

The Rancher UI

https://rancher.com

Apache License 2.0

450 stars 256 forks source link

Removing finalizers from mgmt cluster breaks the UI #9393

Open a-blender opened 1 year ago

a-blender commented 1 year ago

Setup

Rancher version: 2.7-head
Rancher UI Extensions:
Browser type & version: Mac Safari

Describe the bug

If finalizers on the management cluster are removed, deleting the management cluster while the provisioning cluster object still exists the dashboard hangs. Trying to access the Cluster Management tab gives me a null undefined id error or reloads to another page location.

To Reproduce

Provision a single node RKE2 node driver cluster via the rancher UI
Delete the mgmt cluster (or remove finalizers)
Navigate to Cluster Management / around the UI

Result

Expected Result

Screenshots

Additional context

Workaround: remove finalizers via kubectl from the prov cluster object. This causes the stuck cluster to get successfully removed and terraform destroy cmd to complete.

gaktive commented 1 year ago

@Andy-Blendermann thanks for finding this. Is this a blocker for Q3 or can this wait for Q4?

richard-cox commented 1 year ago

I'm not sure deleting the mgmt cluster whilst the provisioning cluster exists is a supported case. I'd guess it should be the other way around? We would need someone on the backend to confirm

a-blender commented 1 year ago

@gaktive Nope, not a blocker! Just something that took down our dev environment UI when I force removed a cluster. @jakefhyde is removing the prov cluster first, then mgmt the expected process if someone has to, for some reason, force remove a stuck cluster?

gaktive commented 1 year ago

@Andy-Blendermann cool, thanks for clarifying! We'll target Q4 at the earliest.

gaktive commented 1 year ago

Removing the management cluster first is an odd scenario since I think that'd break a lot of other things but I'll ask around.

jakefhyde commented 1 year ago

It's not expected at all from a backend perspective, but we should handle it gracefully if possible, as currently it becomes much harder to navigate to a specific cluster to fix the issue. It's definitely something a user may run into when trying to clean up a cluster manually (which I believe is how @a-blender encountered the issue initially). Agree though, not a priority at all.