* skip node delete from removed member
Signed-off-by: galal-hussein <hussein.galal.ahmed.11@gmail.com>
* use grpc errors
Signed-off-by: galal-hussein <hussein.galal.ahmed.11@gmail.com>
* go imports
Signed-off-by: galal-hussein <hussein.galal.ahmed.11@gmail.com>
* exit if node is the etcd that being removed
Signed-off-by: galal-hussein <hussein.galal.ahmed.11@gmail.com>
* Set etcd timeouts using values from k8s instead of etcdctl
Fix for one of the warnings from #2303
* Use etcd zap logger instead of deprecated capsnlog
Fix for one of the warnings from #2303
* Remove member self-promotion code paths
* Add learner promotion tracking code
* Fix RaftAppliedIndex progress check
* Remove ErrGRPCKeyNotFound check
This is not used by v3 API - it just returns a response with 0 KVs.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
The default http client does not have an overall request timeout, so
connections to misbehaving or unavailable servers can stall for an
excessive amount of time. At the moment, just attempting to join
an unavailable cluster takes 2 minutes and 40 seconds to timeout.
Resolve that by setting a reasonable request timeout.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
According to @galal-hussein this is dead code that was probably brought
over from Kine. I certainly couldn't figure out what it is supposed to
be doing.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
We should ignore --token and --server if the managed database is initialized,
just like we ignore --cluster-init. If the user wants to join a new
cluster, or rejoin a cluster after --cluster-reset, they need to delete
the database. This a cleaner way to prevent deadlocking on quorum loss,
and removes the requirement that the target of the --server argument
must be online before already joined nodes can start.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
It's a bad practice to install packages via rpm directly. It's better to install all packages with Yum/Dnf. It's also possible to install packages directly via an URL, which is the purpose of this PR.
Wants= is required to actually set the dependency on network-online.service
After= is required or k3s.service will be started at the same time as network-online.service
In network environments with slow DHCP, both are required to ensure valid network configuration for k3s
Signed-off-by: Adam Farden <adam@farden.cz>
Adds the line `After=network-online.target` to the k3s systemd service
file. This applies the fix mentioned in
[this GH comment](https://github.com/rancher/k3s/issues/1626#issuecomment-642253812)
which I can confirm makes k3s networking survive reboot in Raspbian
Buster.
[It appears, in some docs I found](https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files)
that this is a recommended and usual way of specifying that we need the
target to be _completed_ before starting k3s. Using just the `Wants=`
directive doesn't work for this task, you have to add both directives
at once to do this. Quote:
> `Wants=`: This directive is similar to `Requires=`, but less strict.
> `Systemd` will attempt to start any units listed here when this unit
> is activated. If these units are not found or fail to start, the
> current unit will continue to function. This is the recommended way to
> configure most dependency relationships. **Again, this implies a
> parallel activation unless modified by other directives**
> [...]
> `After=`: The units listed in this directive will be started before
> starting the current unit. This does not imply a dependency
> relationship and **one must be established through the above
> directives if this is required.**
- _(Emphasis mine)_
Signed-off-by: Matthew Clive <arcticlight@arcticlight.me>
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
This attempts to update logging statements to make them consistent
through out the code base. It also adds additional context to messages
where possible, simplifies messages, and updates level where necessary.
The list is the same across architectures, and is validated against the
list in git as part of CI... so there's no reason to be pushing it from
every pipeline. It's also causing conflicts when multiple pipelines try
to upload it at the same time.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
