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

upcoming: [M3-8881, M3-8885] - Add and update beta endpoints and queries for LKE-E #11302

Merged

Conversation

mjac0bs
Copy link
Contributor

@mjac0bs mjac0bs commented Nov 21, 2024

Description 📝

This PR supports the /v4beta endpoints and queries necessary for LKE-E.
(Except /regions, which will be done in M3-8884.)

Changes 🔄

  • Added two new types: KubernetesTieredVersion and KubernetesTier
  • Updated existing interfaces for CreateKubeClusterPayload and KubernetesCluster with new tier field
  • Added beta endpoints and queries for v4beta/lke/versions/{tier} and v4beta/lke/versions/{tier}/{versionId}, and v4beta/lke/clusters
  • Added/updated query keys for GET /clusters and GET /cluster functions to use the beta endpoint if LKE-E feature is enabled
  • No UI changes

Preview 📷

API Spec: POST /v4beta/lke/clusters

Screenshot 2024-11-21 at 8 11 09 AM

API Spec: GET /v4beta/lke/clusters

Screenshot 2024-11-21 at 8 11 28 AM

API Spec: GET /v4beta/lke/clusters/{clusterID}

Screenshot 2024-11-21 at 8 11 38 AM

API Spec: GET /v4beta/lke/versions/{tier}

Screenshot 2024-11-21 at 8 11 58 AM

API Spec: GET /v4beta/lke/versions/{tier}/{versionId}

Screenshot 2024-11-21 at 8 12 29 AM

How to test 🧪

Prerequisites

(How to setup test environment)

  • Add the LKE-E tag on your account (see 'LKE-Enterprise Project Tracker')
  • Or use the MSW Preset > Account > LKE-Enterprise Enabled

Verification steps

(How to verify changes)

  • Confirm there are no regressions when creating and getting a cluster with APL enabled.
  • Confirm the changes match the API spec (by viewing the spec in the Preview section above)
  • Everything else will be tested in the UI tickets to come.

As an Author, I have 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

@mjac0bs mjac0bs self-assigned this Nov 21, 2024
@mjac0bs mjac0bs marked this pull request as ready for review November 21, 2024 16:58
@mjac0bs mjac0bs requested a review from a team as a code owner November 21, 2024 16:58
@mjac0bs mjac0bs requested review from hkhalil-akamai and harsh-akamai and removed request for a team November 21, 2024 16:58
Comment on lines 15 to +19
apl_enabled?: boolean; // this is not the ideal solution, but a necessary compromise to prevent a lot of duplicated code.
/** Marked as 'optional' in this existing interface to prevent duplicated code for beta functionality, in line with the apl_enabled approach.
* @todo LKE-E - Make this field required once LKE-E is in GA. tier defaults to 'standard' in the API.
*/
tier?: KubernetesTier;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Context for this is here.

Copy link

github-actions bot commented Nov 21, 2024

Coverage Report:
Base Coverage: 86.81%
Current Coverage: 86.81%

Comment on lines 201 to 213
/** getKubernetesTieredVersion
*
* Returns a single tiered Kubernetes version by ID from the beta API.
*
*/

export const getKubernetesTieredVersion = (versionID: string) =>
Request<KubernetesTieredVersion>(
setMethod('GET'),
setURL(
`${BETA_API_ROOT}/lke/versions/:tier/${encodeURIComponent(versionID)}`
)
);
Copy link
Contributor

Choose a reason for hiding this comment

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

Struggling to understand the purpose of this endpoint... my understanding is that it just returns the same data from the request (the version and the tier)... will this change in the future?

Copy link
Contributor Author

@mjac0bs mjac0bs Nov 21, 2024

Choose a reason for hiding this comment

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

This beta endpoint (which I should have named getKubernetesTieredVersionBeta, fixed this in last commit) returns a single version (which is now version id + tier). The other new beta endpoint (getKubernetesTieredVersionsBeta) returns multiple versions.

The existing endpoints (/versions/{versionId} and /versions) only return a version id (so only standard, e.g. current LKE versions), so in a sense they will be 'deprecated'.

Does that help any?

Edit: Yeah, after re-reading this comment "it just returns the same data from the request", you're right... and we also don't seem to use its older counterpart getKubernetesVersion anywhere in CM. Do we keep these in the apiv4 for completeness? (As to 'will this change the future' - not in any specs I've seen so far.)

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine with keeping it in apiv4 for completeness

useBetaEndpoint
? getAllKubernetesClustersBeta()
: getAllKubernetesClusters(),
queryKey: [useBetaEndpoint],
Copy link
Contributor

Choose a reason for hiding this comment

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

Should the queryKey be a boolean?

Copy link
Contributor Author

@mjac0bs mjac0bs Nov 21, 2024

Choose a reason for hiding this comment

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

It currently is a boolean - do you think it should be something else, like [useBetaEndpoint ? 'beta' : 'nonbeta']?

image

This was following a pattern that is already working for APL with the singular getKubernetesCluster endpoint (which we'd want to replicate here with getKubernetesClusters). My understanding is that we add something (boolean) to the query key to be able to switch between beta and non-beta endpoints and cache each response correctly.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I think a string would make more sense and it would be easier from a quick glance looking at it from the React Query dev tools

image

Copy link
Contributor Author

@mjac0bs mjac0bs Nov 21, 2024

Choose a reason for hiding this comment

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

As long as we make the change consistent across all query keys where we're toggling between endpoints, that sounds fine to me. (Unless I'm missing a particular reason that @bnussman-akamai chose a boolean.)

What's the correct term for "non-beta"? "public", "final"... just null? 'v4beta' and 'v4'?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I went with v4 and v4beta in 6f28d2a - lmk if you have any other suggestions or see anything unexpected with caching.

Account with the LKE-E customer tag and without being enrolled in APL beta Account without the LKE-customer tag and without being enrolled in APL beta
Screenshot 2024-11-21 at 2 13 51 PM Screenshot 2024-11-21 at 2 11 15 PM

Copy link
Member

Choose a reason for hiding this comment

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

Nice. v4 and v4beta is a good idea. 🧠 I just picked the boolean earlier because it was quick and easy.

@linode-gh-bot
Copy link
Collaborator

Cloud Manager UI test results

🎉 454 passing tests on test run #5 ↗︎

❌ Failing✅ Passing↪️ Skipped🕐 Duration
0 Failing454 Passing2 Skipped106m 1s

Copy link
Contributor

@hana-akamai hana-akamai left a comment

Choose a reason for hiding this comment

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

  • Confirm there are no regressions when creating and getting a cluster with APL enabled.
  • Confirm the changes match the API spec (by viewing the spec in the Preview section above)

@hana-akamai hana-akamai added the Add'tl Approval Needed Waiting on another approval! label Nov 22, 2024
@mjac0bs mjac0bs added Approved Multiple approvals and ready to merge! and removed Add'tl Approval Needed Waiting on another approval! Ready for Review labels Nov 22, 2024
@mjac0bs mjac0bs merged commit 3ca4f1d into linode:develop Nov 22, 2024
23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Approved Multiple approvals and ready to merge! LKE-Enterprise
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants