Avoid nil panic on non-GKE GCP clusters (K3s) #957
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.
What does this PR change?
A user running K3s on GCP is encountering a nil panic
caused by our parsing logic for the node.kubernetes.io/instance-type
label. On GCP, we expect GCP node type formats (xx-xx-xx) with
one or two dashes. The K3s cluster sets this value as just "k3s" in the
user's cluster.
By adding a guard on the length of the parsed result we avoid the panic.
Does this PR rely on any other PRs?
N/A
How does this PR impact users? (This is the kind of thing that goes in release notes!)
Fix a bug where a nil panic would occur when running on K3s clusters on GCP.
Links to Issues or ZD tickets this PR addresses or fixes
How was this PR tested?
Deployed to a GKE cluster to confirm nothing broke (no errors observed) and added unit test for the user's specific case.
Have you made an update to documentation?
N/A