Look at all namespace unless overridden #370
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Removes the default setting where not specifying the kubernetes-namespace defaults it to whatever namespace the controller is running in
Why is this needed
tinkerbell/cluster-api-provider-tinkerbell#385
With this change, you can create hardware resources in different namespaces.
Fixes: #
How Has This Been Tested?
We have a cluster-api setup where we're adding some bare metal nodes to a cluster.
With this change, the hardware resources that previously only worked from the tink-system namespace now also work from a different namespace. I also tested the old working setup and that still works as well.
The change is minimal, so it shouldn't impact much.
I haven't tested if the --kubernetes-namespace setting would restrict it to one namespace again.
How are existing users impacted? What migration steps/scripts do we need?
The Role and RoleBinding resources in the helm chart (or whatever other deployment method) need to be changed to ClusterRole and ClusterRoleBinding, otherwise it will not be able to read from the other namespaces.
Otherwise no migration steps are needed, unless users have multiple instances of hegel running in different namespaces, or have another reason why they specifically don't want resources in a different namespace to be picked up.
This could probably be avoided by having the helm chart add the kubernetes-namespace argument to the deployment and have it pull the value from the downward api somehow, but it seems to me that having it default to looking at all namespaces would be preferrable for most users.
Checklist:
I have: