* Update docs to include s390x arch
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x drone pipeline
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Install trivy linux arch only for amd64
This is done so that trivy is not installed for s390x arch
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x arch if condition for Dockerfile.test
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x arch in install script
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add s390x GOARCH in build script
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Add SUFFIX s390x in scripts
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Skip image scan for s390x arch
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Update klipper-lb to version v0.3.5
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Update traefik version to v2.6.2
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Update registry to v2.8.1 in tests which supports s390x
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
* Skip compact tests for s390x arch
This is done because compact test require a previous k3s version which supports s390x and it is not available
Signed-off-by: Venkata Krishna Rohit Sakala <rohitsakala@gmail.com>
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>
Should hopefully fix issues that cropped up with arm builds failing due
to the sqlite libs from alpine 3.10 no longer being compatible with
alpine edge, which was probably never a safe assumption to begin with.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
When k3s is installed on an OS with default high ulimits, performance
issues can be observed. This was discovered on CoreOS where the default
value is 1073741816. Symptoms include very slow file operations such
as installing a Rook/Ceph cluster will take ~6 hours instead of ~10 minutes.
A google search for 'container LimitNOFILE' will show that most major
projects set this already, including the (unused) containerd systemd unit
found in this repository at /vendor/github.com/containerd/containerd/containerd.service
k3OS is not affected becuasse the default there is already 1048576.
See description in coreos/fedora-coreos-tracker#329
Modified installer produces a k3s-server and k3s-agent systemd
service, with env files located in /etc/rancher/k3s.
The k3s-server service may be started without modification but
k3s-agent requires a token and url modification to the
/etc/rancher/k3s/k3s-agent.env file for functionality.
The k3s-server service will conflict with the k3s-agent service,
so both may not be started at the same time.
Creates ./package/rpm/ repo dir for rpm specific resources and
relocates k3s.spec.
Manuel Buil