upcoming: [M3-8848] - Update Kubernetes version Autocomplete to filter on LKE-E versions

[mjac0bs]

Description 📝

When a user selects LKE-Enterprise as their cluster type, we will need to ensure the Kubernetes versions for the enterprise tier are displayed and the versions for the standard tier are not.

Note: Also pending approval from UX, who has noted that there is a potential drop off at the version field in LKE during cluster creation. Potential helper text/tooltip may be added.

Changes 🔄

• Fixed a missing return in the useKubernetesTieredVersionsQuery hook
• Used this hook in the Create Cluster flow to fetch tiered ('standard' and 'enterprise') versions
• Updated the logic for the Kubernetes Version autocomplete selection to use tiered versions with the LKE-E feature enabled
• Updated the payload with a tier if the LKE-E feature is enabled so that the enterprise cluster can be created
• Updated test coverage in lke-create.spec.ts

Preview 📷

Screen.Recording.2024-12-03.at.8.37.00.AM.mov

How to test 🧪

Prerequisites

(How to setup test environment)

• Have LKE-E customer tag on your account (see Project Tracker)

Verification steps

(How to verify changes)

• Go to http://localhost:3000/kubernetes/create
• Confirm the following with the feature flag ON:
  • The version select shows the latest standard LKE version by default (e.g. 1.31)
  • When the user selects LKE Enterprise as their cluster type, the version select shows only LKE-E versions
  • The user can toggle back to standard versions by selecting LKE as the cluster type
  • The user can create an enterprise cluster by selecting a region in which LKE-E is available (e.g. Chicago), a current enterprise k8 version, and submitting the form
  • The user can create a standard cluster by selection any region, a current standard k8 version, and submitting the form
• Confirm the following with the feature flag OFF:
  • No regressions to the version select and the existing endpoint (/versions) is used
  • No regressions to the user's ability to create an LKE cluster
• Confirm test coverage passes:

yarn cy:run -s "cypress/e2e/core/kubernetes/lke-create.spec.ts"

Author Checklists

As an Author, to speed up the review process, I considered 🤔

👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support

• I have read and considered all applicable items listed above.

As an Author, before moving this PR from Draft to Open, I confirmed ✅

• All unit tests are passing
• TypeScript compilation succeeded without errors
• Code passes all linting rules

[jdamore-linode]

Thanks Mariah, the test is looking good! I really like how you're building it out piece-by-piece alongside the rest of the feature work.

I am seeing some rare failures when running it repeatedly, but couldn't figure out if it's a test issue or an app issue. I posted a comment with everything I know. Hoping to take a closer look in the next day or so, but happy to help out if you have any questions, trouble reproducing, etc.!

[jdamore-linode]

I'm getting intermittent* failures here where the v1.31.1+lke1 entry isn't present in the autocomplete dropdown.

In each case I've observed, Cloud is making the expected GET request to lke/versions/enterprise and Cypress is mocking the response with the right data, so I'm not certain whether this is a test issue or possibly a bug.

Hoping to spend more time looking at this, but wanted to give you a heads up in the meantime!

* To elaborate on "intermittent": I'm running the test using repeat 10 cy:run ... and seeing the failure 1-2 times per every 10 attempts.

lke-create.spec.ts.mp4

[jdamore-linode]

Suggested change

	mockGetTieredKubernetesVersions('enterprise', [
	latestEnterpriseTierKubernetesVersion,
	]).as('getTieredKubernetesVersions');
	mockGetTieredKubernetesVersions('enterprise', [
	latestEnterpriseTierKubernetesVersion,
	]).as('getTieredKubernetesVersions');
	mockGetTieredKubernetesVersions('standard', []);

I wonder if there'd be any benefit to mocking the standard versions response so Cloud doesn't try to send repeated requests to that endpoint during the test?

It doesn't seem to make a difference when it comes to the test failure I mentioned, though 😕

[linode-gh-bot]

Cloud Manager UI test results

🎉 465 passing tests on test run #3 ↗︎

❌ Failing	✅ Passing	↪️ Skipped	🕐 Duration
0 Failing	465 Passing	2 Skipped	107m 16s