Remove `topology` configmap on kuadrant operator uninstall

[eguzki]

Link the lifecycle of the kuadrant operator with the topology configmap. Currently, when the operator starts, it will create and maintain the topology configmap in the namespace where the operator is deployed. It is missing the implementation of the removal of the topology configmap when the operator is deleted.

Note: The ConsolePlugin resource, together with the associated deployment and service, follows the life events of the topology configmap. When the topology is created, so it is the ConsolePlugin (on openshift). Whereas when the topology is deleted, so it is the ConsolePlugin and associated resources. The ConsolePlugin was introduced in #884

[maleck13]

Is this essential for v1?

[eguzki]

I would say it is not.

[eguzki]

Release attribute now is unset

[david-martin]

I'm wondering when to actually delete the topology configmap.
Specifically, what does it mean 'when the operator is deleted'.
I'm not sure how we'd hook into that part of the lifecycle.
Perhaps we tie it to the created/deletion of the Kuadrant CR?

Thoughts @eguzki

[Boomatang]

I don't think you can (or should) tie this to the creation and deletion of the Kuadrant CR. What happens in the console plugin if that topology is not there? If you create a policy when the kuadrant CR is not present, the operator will accepted it, but raise a MissingResource error stating that kuadrant is not installed. The resource is in the topology at this stage.

In a prefect world the console plugin would show any policies that have errors in the graph. I don't think that happens today.

I think the removal has to be linked into the lifecycle of the operator. Could it be a simple as adding an ownership to the configmap that links back to the kuadrant deployment CR.

There is a future world that is some way away, but might be worth the consideration. In the future there will be an Open Architecture that could used to remove the need for the configmap all together.

[guicassolato]

I don't think you can (or should) tie this to the creation and deletion of the Kuadrant CR.
+1

One can have multiple resources, including Kuadrant policies, without necessarily having a Kuadrant CR. Even if Kuadrant is not fully functional without it⸺and especially because it's not functional⸺this state should be reflected in the topology.

It's also possible to have multiple Kuadrant CRs in a cluster. Users will also want to see that in the topology graph.

IOW, a topology without a Kuadrant CR (or with multiple ones) communicate something to the user and therefore these two objects, Kuadrant CR and topology, should not be coupled together.

[eguzki]

I was thinking on adding an empty topology configmap as part of the bundle of the operator. Either Helm or OLM would delete it when the operator is being decommissioned. Initially, the configmap would be empty, having the operator fill with some content as soon as it starts.