The main is doing flag validation through pflags, then
did further validation by involving the constructors.
With the recent refactor on the commit "Refactor constructors"
in this branch, we moved away from that pattern.
However, it means we reintroduced a log dependency into our
external API, and the external API now had extra validations
regardless of the type.
This is unnecessary, so I moved away from that pattern, and
moved back all the validation into a central place, internal,
which is only doing what kured would desire, without exposing
it to users. The users could still theoretically use the proper
constructors for each type, as they would validate just fine.
The only thing they would lose is the kured internal decision
of validation/precedence.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, a bit of the validation is done in main, while
the rest is done in each constructor.
This fixes it by create a new global constructor in checkers/reboot to
solve all the cases and bubble up the errors.
I prefered keeping the old constructors, and calling them, this
way someone wanting to have a fork of the code could still create
directly the good checker/rebooter, without the arbitrary decisions
taken by the generic constructor.
However, kured is not a library, and was never intended to be
usable in forks, so we might want to reconsider is part 2 of the
refactor.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Implementation details of lock should not leak into the calling
methods.
Without this path, calls are a bit more complex
and error handling is harder to find.
This is a problem for long term maintenance, as it
is tougher to refactor the locks without impacting the main.
Decoupling the two (main usage of the lock, and the lock
themselves) will allow us to introduce other kinds of locks
easily.
I solve this by inlining into the daemonsetlock package:
- including all the methods for managing locks from the main.go
functions. Those were mostly doing error handling
where code became no-op by introducing multiple
daemonsetlock types
- adding the lock release delay part of lock info
I also did not like the pattern include in Test method,
which added a reference to nodeMeta: It was not very clear
that Test was storing the current metadata of the node,
or was returning the current state. (Metadata here only means unschedulable).
The problem I saw was that the metadata was silently
mutated from a lock Test method, which was very not obvious.
Instead, I picked to explicitly return the lock data instead.
I also made it explicit that the Acquire lock method
is passing the node metadata as structured information,
rather than an interface{}. This is a bit more fragile
at runtime, but I prefer having very explicit errors if
the locks are incorrect, rather than having to deal with
unvalidated data.
For the lock release delay, it was part of the rebootasrequired
loop, where I believe it makes more sense to be part of the
Release method itself, for readability. Yet, it hides the
delay into the implementation detail, but it keeps the
reboot as required goroutine more readable.
Instead of passing the argument rebootDelay as parameter of the
rebootasrequired method, this refactor took creation of the lock
object in the main loop, close to all the variables, and then
pass the lock object to the rebootasrequired. This makes the
call for rebootasrequired more clear, and lock is now
encompassing everything needed to acquire, release, or get
info about the lock.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
If the notification url configuration is known to be not working,
this should be raised as an error, not a warning.
Without this, it would be easy to miss a misconfiguration.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, the main loop is in need of 3 functions to simply
parse flags and env variables (excluding input validation).
This is a bit more complex than it should, especially since
we only need to parse command line flags and env vars.
This fixes it by simply using pflags (which we were already
using) instead of pflags + viper + cobra (for which we
do not have any benefit), and removing all the methods
outside the mapping of env var with cli flag.
The main code is now far simpler: It handles the reading,
parsing, and returning in case of error.
As we do not bubble up errors from rebootasRequired yet,
this is good enough at this moment.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, we have no validation of the data in command/signal
reboot.
This was not a problem in the first refactor, as the constructor
was a dummy one, without validation.
However, as we refactoed, we now have code in the root method
that is validation for the reboot command. This can now be
encompassed in the constructor.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this patch, the rebooter interface has data which is
not related to the rebooter interface. This should get removed
to make it easier to maintain.
The loss comes from the logging, which mentioned the node.
In order to not have a regression compared to [1], this ensures
that at least the node to be rebooted appears in the main.
[1]: https://github.com/kubereboot/kured/pull/134
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, the checkers are only shell calls: test -f
sentinelFile, or sentinelCommand.
This changes the behaviour of existing code to test file for
sentinelFile checker, and to keep the sentinel command as
a command.
However, to avoid having validation in the root loop, it moves
to use a constructor to cleanup the code.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, the variable name is hard to follow.
This fixes it by cleaning up the var name.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, validations are all over the place.
This moves some validations directly into the function, to
make the code simpler to read.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, it makes the code a bit harder to read.
This fixes it by extracting the method.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, the interface and the code to reboot is
a bit more complex than it should be.
We do not need setters and getters, as we are just
instanciating a single instance of a rebooter interface.
We create it based on user input, then pass the object
around. This should cleanup the code.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
* Move to stable kind cluster filenames
Without this, we have to rename files at every version.
This is really unnecessary, we should only change the files
and be done with it.
This is a problem, as if we move to programmatic test running,
the tests would need to be mutatated at every k8s version.
With this model, we know that only the kind-cluster files
need to be modified for the tests to ba automatically
adapted.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
* Create e2e from go tests interface
Without this, e2e tests need tons of manual work to
test locally, and the results are not easily exposed.
People are less likely to use the e2e tests if they
are tough to use outside the CI.
This commit makes it easier to run tests locally,
and ensures the CI is closer to the Makefile.
At the same time, this removes debt in the github
worfklows: By switching to newer versions of kind,
we can remove the very old workaround for the
failed to attach pid 1.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
* Add node stays as cordonned test
Without this, impossible to prove that the node stays as cordonned
after a reboot by kured.
This refactor also adds the test in the CI, and makes sure the
CI is a bit simpler, by using matrix more extensively.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
* Use hack dir instead of .tmp
This is more idiomatic.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
---------
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, some CI jobs are flaky or slow due to the following
issues:
- Triggering a reboot cause an unrecoverable boot loop.
This fixes it by restarting the containers that are incorrectly
exited.
- API server is down while operations happen.
This fixes it by ensuring at least one API server is up. In this
case, we don't add a reboot marker on the unique api server.
- The amount of nodes in a test environment is larger than
necessary.
This fixes it by ensuring two nodes are required to reboot.
This is enough for concurrency, and for the e2e testing.
- The wait time between operations is high, and can cause
a heartbeat to be missed in the check script.
This fixes it by checking more often, at the expense of
more logging. This is compensated by increasing the amount
of tries.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
Without this, the CI would automatically point DH_ORG to
kubereboot/kured on ghcr, instead of pointing to the owner
of the repo.
This makes the CI smoother.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
