Implement collection GETs for node pools #883
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 5 commits
November 22, 2024 15:31
Works for any document type now, and just stores a slice rather than the entire cache for that document type.
A new function NewQueryItemsSinglePageIterator alters the behavior of QueryItemsIterator to stop after the first "page" of items and record the Cosmos DB continuation token. The continuation token can be retrieved from the iterator with GetContinuationToken. A QueryItemsIterator created with NewQueryItemsIterator will never have a continuation token because it iterates until the last item. The in-memory cache also adds a GetContinuationToken method to its iterator implementation to fulfill the interface contract, but it always returns an empty string.
For CosmosDBClient, the maxItems argument controls the type of iterator returned. A positive maxItems returns a single- page iterator with a possible continuation token, otherwise the iterator continues until the last item. Since the in-memory cache does not have continuation tokens, the maxItems argument is ignored. This also drops the resourceType argument. Callers first need to parse the iterator items into resource documents before checking the resource type.
Similar to QueryItemsIterator for Cosmos DB pagination.
I was surprised to discover the collection endpoint for node pools is a valid resource ID (according to ParseResourceID), whereas the collection endpoints for clusters (by subscription and by resource group) are not. This required tweaking the static validation middleware, which was blocking node pool collection requests because the parsed resource ID had no resource name.
mbarnes
force-pushed
the
node-pool-collection-get
branch
from
10ed16e
to
807f48a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 this PR does
Per the Resource Provider Contract rules for Get Resource (specifically rule RPC-Get-V1-05), the only collection GET endpoint required for nested tracked resources is on the parent resource:
I managed to generalize the
Frontend.ArmResourceListhandler function for both clusters and node pools. The logic there was already fairly complicated and I wanted to avoid having two copies of it.There's also a bunch of enhancements here to my "failable push iterator" pattern, such as extending it to encapsulate pagination of Cluster Service list responses. Unfortunately I can't really add unit tests for these since they depend on actual Cluster Service responses.
Jira: I couldn't find a specific user story for this, but
Link to demo recording:
Special notes for your reviewer