Improve manifest stack application w.r.t. CRDs #4516
Merged
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
twz123
force-pushed
the
try-all-resources
branch
2 times, most recently
from
c8c8dae to
d545390
Compare
|
This pull request has merge conflicts that need to be resolved. |
This will prevent the Builder to try to get a REST mapping for all the resources from the API server, which will fail in case of custom resources whose CRDs weren't applied yet. The error returned from the builder looked like this: > unable to build resources: resource mapping not found for name: "fooResource" namespace: "default" from "/var/lib/k0s/manifests/foo/resources.yaml": no matches for kind "Foo" in version "example.com/v1" > ensure CRDs are installed first Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
This makes it easier to refactor the Applier. Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
When applying a stack, the Stack knows best when it makes sense to reset the RESTMapper. Move the cache invalidation out of the Applier into the Stack, and trigger it whenever a REST mapping for a given kind was not found. Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
This reduces the boilerplate in the callers and allows for the Stack to use typed clients, if required. Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
Watching CRDs has more and more usages in k0s. Introducing a common helper makes sense and reduces the amount of copy/pasted type aliases. Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
As a result, the Applier requires fewer retries when applying stacks that contain both custom resources and their definitions. Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
This allows k0s to apply stacks that are not well ordered, i.e. that don't declare dependencies before their dependents. By attempting to apply each resource, the dependencies will eventually be applied, allowing the dependents to be applied on the next retry. Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
Make sure that stacks that are badly ordered are eventually applied in their entirety. Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
jnummelin
approved these changes
Jun 11, 2024
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.
Description
Prevent the Applier's resource.Builder to try to get a REST mapping for all the resources from the API server, which will fail in case of custom resources whose CRDs weren't applied yet. The error returned from the builder looked like this:
Collect resource errors when applying stacks: This allows k0s to apply stacks that are not well ordered, i.e. that don't declare dependencies before their dependents. By attempting to apply each resource, the dependencies will eventually be applied, allowing the dependents to be applied on the next retry.
During the stack application, reset the REST mapper each time it can't find a mapping to ensure that the error is not due to out-of-date cached data.
Wait for CRDs to be established after their application: As a result, the Applier requires fewer retries when applying stacks that contain both custom resources and their definitions.
Add an integration test to make sure that stacks that are badly ordered are eventually applied in their entirety.
Type of change
How Has This Been Tested?
Checklist: