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

The first time an EKS cluster is created its provider/distro is initially shown as imported/imported #12883

Open
mantis-toboggan-md opened this issue Dec 12, 2024 · 0 comments
Labels
area/eks kind/bug QA/dev-automation Issues that engineers have written automation around so QA doesn't have look at this
Milestone

Comments

@mantis-toboggan-md
Copy link
Member

mantis-toboggan-md commented Dec 12, 2024

Setup

  • Rancher version: v2.11-d224815d7cfbf4194db1ffdfb04676d55d1a2062-head
  • Rancher UI Extensions: none
  • Browser type & version: firefox

We may need to tackle #12882 first.

Describe the bug
Originally reported here. The first time a user creates an EKS cluster, its provider/distro in the cluster management cluster list view is shown as imported/imported.

To Reproduce

  1. Bring up a new rancher instance
  2. create an EKS cluster. Default values are fine.
  3. Observe the cluster list view immediately after creating the cluster

Result
The new cluster's provider/distro is imported/imported

Expected Result
The new cluster's provider/distro should be Amazon EKS

Screenshots
image

Additional context
It seems that the mgmt cluster status.driver and status.provider are undefined initially. I think this bug is only obvious on the first EKS cluster because that first cluster is slower to provision. If I open a second window to watch the table as I create another EKS cluster, I do see it listed as imported/imported, but only for 1-2 seconds at most.

@mantis-toboggan-md mantis-toboggan-md added this to the v2.11.0 milestone Dec 12, 2024
@github-actions github-actions bot added the QA/dev-automation Issues that engineers have written automation around so QA doesn't have look at this label Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/eks kind/bug QA/dev-automation Issues that engineers have written automation around so QA doesn't have look at this
Projects
None yet
Development

No branches or pull requests

1 participant