Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix EKS Discover User Task reporting #50989

Merged
merged 3 commits into from
Jan 13, 2025
Merged

Conversation

marcoandredinis
Copy link
Contributor

@marcoandredinis marcoandredinis commented Jan 13, 2025

The clusterNames slice and clusterByNames key set must be the same.

When there was two groups of EKS Clusters, one with App Discovery enabled and another one with it disabled, we had different set of clusters being processed.
clusterNames had all the EKS Clusters, while clusterByNames only had the EKS Clusters for one of the processing groups (either AppDiscovery=on or AppDiscovery=off).
This meant that when the EnrollEKSClusters returned an error, we looked up the map, but it might be the case that that particular EKS Cluster was not configured for the current processing group. So, the clusterByNames[r.EksClusterName] returned a nil value, which resulted in a panic.

changelog: Fix a panic that occurred when EKS Auto Discovery was configured at least two times for an Integration, where one of them had App Auto Discovery enabled and the other one didn't.

The `clusterNames` slice and `clusterByNames` key set must be the same.

When there was two groups of EKS Clusters, one with App Discovery
enabled and another one with it disabled, we had different set of
clusters being processed.
`clusterNames` had all the EKS Clusters, while `clusterByNames` only had
the EKS Clusters for one of the processing groups (either
AppDiscovery=on or AppDiscovery=off).
This meant that when the `EnrollEKSClusters` returned an error, we
looked up the map, but it might be the case that that particular EKS
Cluster was not configured for the current processing group.
So, the `clusterByNames[r.EksClusterName]` returned a nil value, which
resulted in a panic.
Copy link
Collaborator

@r0mant r0mant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if this is a robust fix, relying on clustersByName containing the same keys as clusterNames seems pretty fragile and still leaves room for a mistake later for a non-existent key on the line that @tigrato pointed out:

cluster := clustersByName[r.EksClusterName]

Can we make the map indexing there safer too as a part of this fix?

@marcoandredinis
Copy link
Contributor Author

I don't know if this is a robust fix, relying on clustersByName containing the same keys as clusterNames seems pretty fragile and still leaves room for a mistake later for a non-existent key on the line that @tigrato pointed out:

cluster := clustersByName[r.EksClusterName]

Can we make the map indexing there safer too as a part of this fix?

I'll add a check there 👍

@r0mant r0mant added this pull request to the merge queue Jan 13, 2025
Merged via the queue into master with commit 62ad3fe Jan 13, 2025
41 checks passed
@r0mant r0mant deleted the marco/fix_usertask_eks_report branch January 13, 2025 20:18
@public-teleport-github-review-bot

@marcoandredinis See the table below for backport results.

Branch Result
branch/v17 Create PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants