-
Notifications
You must be signed in to change notification settings - Fork 453
Apply Helm Stack in-memory #6742
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
Draft
twz123
wants to merge
12
commits into
k0sproject:main
Choose a base branch
from
twz123:direct-crd-application-helm
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains hidden or 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
It was erroneously assigned to a local variable, instead to the one of the outer scope. Fixes: 7b1c25b ("Apply the bootstraprbac stack directly") Signed-off-by: Tom Wieczorek <[email protected]>
The system RBAC component fed an io.Reader into a resource builder to extract unstructured objects and apply them as a stack in a retry loop. This is a pattern that is reusable across components: Move this into its own function in the applier package. Signed-off-by: Tom Wieczorek <[email protected]>
There's no need to write them to the filesystem. Moreover, we can be sure that whenever the CRD component is initialized, the CRDs have been applied successfully, so we don't need to wait for the applier manager to pick things up. Add the etcd member reconciler as a cluster component, just as its CRD stack. This ensures that the CRDs get applied before the reconciler is started. Leave out the Helm stack for now, as this is intertwined with the extensions controller. Both need to be changed in lockstep. Signed-off-by: Tom Wieczorek <[email protected]>
The CRDs are now guaranteed to be applied before it's started. Signed-off-by: Tom Wieczorek <[email protected]>
The CRDs are now guaranteed to be applied before it's started. Signed-off-by: Tom Wieczorek <[email protected]>
…directory This prevents a nil pointer panic from occurring whenever an error happens during directory traversal. Fixes: c1f8c75 ("Cleanup unknown Helm chart manifest files") Signed-off-by: Tom Wieczorek <[email protected]>
Allows for reading the CRDs without using the CRD component. Signed-off-by: Tom Wieczorek <[email protected]>
Remove the custom kubeconfig bootstrapping. Signed-off-by: Tom Wieczorek <[email protected]>
Hardcode the dummy leader elector to always lead. A non-leading leader elector was only required during testing, when a simple function was sufficient. Use a factory function to create the dummy leader elector and make the never channel a private field of it instead of using a global variable. In k0s, there will only ever be one dummy leader elector, if any. Sharing the channel seemed like a good idea, but global state always comes back to bite you. When using testing/synctest, that channel was never associated with a bubble. This made synctest unusable with the dummy elector. Signed-off-by: Tom Wieczorek <[email protected]>
Instead of fiddling with the file system, which is an implementation detail. Signed-off-by: Tom Wieczorek <[email protected]>
Instead of writing the chart manifests to disk, apply them directly from in-memory data. For historical reasons, the CRD and Helm chart resources generated from the k0s configuration reside in the same stack. Therefore, only apply the stack if all the chart resources can be rendered successfully. This ensures that charts are not accidentally removed because the initial config reconciliation is late. Remove the CRD detection loop and start the controller-runtime manager only after the first successful stack application so CRDs are guaranteed to exist before informers come up. Signed-off-by: Tom Wieczorek <[email protected]>
It's no longer in use. All CRDs are now applied in-memory. Signed-off-by: Tom Wieczorek <[email protected]>
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
Follow-up to #6739.
Instead of writing the chart manifests to disk, apply them directly from in-memory data. For historical reasons, the CRD and Helm chart resources generated from the k0s configuration reside in the same stack. Therefore, only apply the stack if all the chart resources can be rendered successfully. This ensures that charts are not accidentally removed because the initial config reconciliation is late.
Remove the CRD detection loop and start the controller-runtime manager only after the first successful stack application so CRDs are guaranteed to exist before informers come up.
Type of change
How Has This Been Tested?
Checklist