Applying cluster-scoped objects with namespace metadata reveals unexpected behavior

[matlec]

Describe the bug
While deploying the local path provisioner with k3s using the addon controller / static manifests I encountered the following behavior:

• when the addon controller discovers and applies the manifest for the first time, the deployment succeeds as expected and all objects are successfully created on the api server
• when the addon controller tries to apply the manifest a second time (e.g. when the addon object is deleted, when the manifest changes, ...), objects that do not have namespace scope (e.g. ClusterRole or ClusterRoleBinding) but reference a namespace in their metadata (e.g. local-path-provisioner-role or local-path-provisioner-bind) are handled incorrectly. Since those objects are persisted without namespace property, compareSets comes to the conclusion that the existing object (with stripped namespace) should be deleted and a new object should be created. process creates objects before it deletes them. This effectively causes non-namespaced objects to be missing.

Proposed fix
The namespace property of objects that are not scoped by namespace can be safely removed before they are being applied. This helps compareSets to identify existing resources and prevent them from being deleted.

[matlec]

As a side note, the local path provisioner manifest should probably be fixed and have the namespace removed from cluster-wide objects :-)

[ibuildthecloud]

Cool, thanks!