-
Bug
-
Resolution: Done
-
Normal
-
ACM 2.9.0, ACM 2.8.1
-
None
-
False
-
None
-
False
-
-
-
Submariner Sprint 2024-18, Submariner Sprint 2024-19, Submariner Sprint 2024-20, Submariner Sprint 2024-21, Submariner Sprint 2024-22
-
Low
-
No
ADescription of problem:
I have a scenario that seems we need a QE test around.
What should happen to the submariner addons when/if the managed clusters are moved into a different clusterSet? *
Version-Release number of selected component (if applicable):
ACM 2.8.1
How reproducible:
not sure, didn't try to reproduce it.
Steps to Reproduce:
- deployed submariner addons in ACM 2.8.1
- note: It failed across both clusters. (not sure, but that is OK, not the focus of this bug ticket)
- I then moved the 2 clusters to another clusterSet - no warnings or concerns about the fact that submariner addons were deployed/failed on members within the clusterSet
- unable to uninstall the Submariner addons
Actual results:
I can freely move managed clusters into another clusterSet even while the submariner addons are deployed (in this case failed).
Expected results:
I would expect something to block the movement of managed clusters into another clusterSet. Or perhaps I don't understand something and it should be fine to move clusters to another clusterSet.
Additional info:
WORKAROUND:
To properly clean up the submariner addons, I did leverage the OCP local-cluster console, Administration > Custom Resource Definitions, to open the ManagedCluster instances.
For every managed cluster in which I had failed Submariner Addons, I viewed the YAML resource, then deleted the finalizer entry containing: `submarineraddon.open-cluster-management.io/submariner-addon-cleanup`