-
Notifications
You must be signed in to change notification settings - Fork 209
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
[WIP] Cleanup Part 2 - Rewrite #1000
Open
evrardjp
wants to merge
22
commits into
kubereboot:main
Choose a base branch
from
evrardjp:second_rewrites
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.
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
evrardjp
force-pushed
the
second_rewrites
branch
from
October 18, 2024 21:17
cc45f87
to
a8e36f0
Compare
This will need a rebase, and reimplementation. But the idea is there. I will update this next week if I have time |
I need to reimplement this from scratch, please ignore my changes from now, until I mention this is ready for review (and [WIP] flag will be removed) |
evrardjp
force-pushed
the
second_rewrites
branch
6 times, most recently
from
November 7, 2024 18:21
c73888b
to
a0d6cec
Compare
This will help make sure the big refactoring does not break the main features. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Extends test coverage to ensure nothing breaks Signed-off-by: Jean-Philippe Evrard <[email protected]>
For tests not running in different kubernetes versions, but have different tests subcases/variants, rephrase the wording "versions" as it is confusing. Signed-off-by: Jean-Philippe Evrard <[email protected]>
evrardjp
force-pushed
the
second_rewrites
branch
from
November 7, 2024 21:15
c86971c
to
d8285de
Compare
This will replace trim, taking a cutset, with Replace. This clarifies the intent to remove a substring. Signed-off-by: Jean-Philippe Evrard <[email protected]>
According to staticcheck, Error strings should not be capitalized (ST1005). This changes the cases for our errors. Signed-off-by: Jean-Philippe Evrard <[email protected]>
A few strings have evolved to eventually remove all the templating part of their strings, yet kept the formatting features. This is incorrect, and will not pass staticcheck SA1006 and S1039. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this, people like myself will forget to run staticcheck. This fixes it by making it part of make tests, which will run with all the fast tests in CI. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this patch, one metric could say "reboot is required" while the rebootAsRequired tick did not run (long period for example). This is a problem, as it leads to misexpectations: "Why did the system not reboot, while the metrics indicate a reboot was required". This solves it by inlining the metrics management within the rebootAsRequired goroutine. Closes: kubereboot#725 Signed-off-by: Jean-Philippe Evrard <[email protected]>
No reason to have all the internal tools (timewindows, taints, locks) as public interfaces. Should someone be crazy to rebuild its own kured, then they would need to load our high level tools: the checkers/blockers/rebooters. Signed-off-by: Jean-Philippe Evrard <[email protected]>
This patches simplifies the principal loop: rebootAsRequired - Previous patch "Fix discrepency metrics <> rebootAsRequired" changed the behaviour of the metrics, ensuring the metrics and the checks for reboots are aligned. However, this meant that the metrics would not be correct for long periods of time if the period is high. This patches therefore clarifies the ticking purpose to avoid users to set large values, as we have seen in multiple questions in the past (ppl were missing that part of the documentation, and could find the name "period" a misnomer). - With the ticking clarified, it was the opportunity to remove the randomization bit. It was very unlikely, even on large clusters, that calls would trigger a storm on the API server. Similarly, the delay was not bringing any value. By removing those two items, the code can be simplified futher by removing the delaytick and its random seed. - However, by ticking more frequently, we now have more calls on the API server, which might have an impact on large clusters. In order to fix that, I reschuffled the loop to quickly know if a reboot is required at each tick, which helps a bit reducing some of the calls. This can be further improved by sharing node/ds info through the calls in the tick in order to make the process more efficient. - A new struct GenericRebooter was introduced to keep data all the rebooters need. For example, here, it keeps the rebootDelay imposed to the reboot function. Each rebooter can implement its own reboot method, but to simplify there the generic rebooter implements a DelayReboot() method, which is then called from all the Reboot methods of the concrete types. - On the way, this commit also changed the RebootBlocked function, to also return the list of the names of (types) blocking the reboot. This is useful to debug, but also can be useful to later expose the content of the blocker into specific metrics. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this, there is no way to tell, by looking at the metrics how much reboot attempts were done, or why they were blocked. This is a problem, as only logs are currently usable to expose the blockers. This fixes it by introducing a new vector holding as labels the node names and the reason of the block. For this, all the blockers have to implement another method in the RebootBlocker interface, namely MetricLabel(), to generate a string containing the block reason. To avoid high cardinality, this is basically a static name based on the struct. I did not choose to use a Stringer interface, as I feel the Stringer interface would make more sense for the blocker data itself (including its specific details, for example pod selector string, etc.). Signed-off-by: Jean-Philippe Evrard <[email protected]>
Wthout this, it will not be possible to use unprivileged commands. This is a problem, as one might want to run a command without the nsenter to pid 1. This fixes it by exposing this to main, the only thing remaining is to use a boolean to expose the feature in a later commit. Signed-off-by: Jean-Philippe Evrard <[email protected]>
delaytick is not used anymore. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this, we are using logrus and the logs are inconsistent. This fixes it by moving to slog, and reviewing all the logs. I added multiple comments to clarify the intent behind the logs. With structured logging, extra data, such as the node, is exposed whenever possible, which makes the logging more consistent. We are not yet using contextes for ticks, it should be done in a later commit. Signed-off-by: Jean-Philippe Evrard <[email protected]>
signal is named SIGRTMIN not SIGTRMIN. It can be confusing for people. As this could also lead to questions, the code clarifies a TODO item: We are still relying on hardcoded ints, instead of evaluating the signal number at run time, as recommended by man (7) signal. Please read man (7) signal for further details. Signed-off-by: Jean-Philippe Evrard <[email protected]>
The current code repeats itself and relies on global vars. This is a problem, as changing the notifications will move code all over, and actually prevents us to use a simple Send() method for all our notifications. This opens the door to a simple sender Sending events to multiple places (webhooks, logs, and a notification service) Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this, we will rely on old urls forever. It has been multiple cycles we removed it, we are now in a good place to remove the vars. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Now that kured is a community project under the CNCF, it might be appropriate to use the official kured name, instead of the old weave.works name. As this is intrusive, there was no occasion to do it before. Because other commits in this branch are intrusive (change of main loop, removing old flags, ...) this is the occasion to clean up the cruft. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this, the flags are becoming a mess. This cleans up the order. Not very important. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this, we use the daemonset lock for annotating the state of the node. This is unnecessary, as we have rights on the node. This is a problem, as it makes the whole lock model more complex, and prevents other implementations for lock. This fixes it by adapting the drain/uncordon functions to rely on the node annotations, by introducing a new annotation, named "kured.dev/node-unschedulable-before-drain" Signed-off-by: Jean-Philippe Evrard <[email protected]>
evrardjp
force-pushed
the
second_rewrites
branch
2 times, most recently
from
November 11, 2024 19:58
a670d69
to
b6d3ba5
Compare
This reduces the global variables, and regroups all the operations in a single place. This will allow further refactor to represent all the k8s operations kured needs on a single node. Signed-off-by: Jean-Philippe Evrard <[email protected]>
Without this patch, while developping (on uncommitted work), the image with previous SHA gets overriden, which leads to mishaps. This fixes it by ensuring only the kured:dev tags (full path and short one) are used everywhere. At the same time, it cleans up the main_test to be more flexible by passing more of the main features as options. Signed-off-by: Jean-Philippe Evrard <[email protected]>
evrardjp
force-pushed
the
second_rewrites
branch
from
November 11, 2024 20:03
b6d3ba5
to
0df8f7c
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.
This is the follow up PR to #990 .
It tackles deeper changes to help on the long term rewrite.
What it does:
It opens the door to the following: