Add generic limits for the lacking components (!6377) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

This MR aims to implement some of the static limits (and requests) required for the majority of the components that are lacking at the moment.

The choice of limits was made after analyzing the patterns of usage (for a period of the last month) provided by the operational team, both in terms of CPU and Limits on the clusters available in IC.

The reason for which requests were added as well was due to the fact that containers use the values that were set in the first place for the limits as defaults for requests. Considering that none of the components that were modified had requests in the first place, adding just the limits would lead to a behavior in which any deployment in a test/lab environment is going to be blocked by the lack of resources. The current configuration of requests/limits was tested in order to be sure that the deployment is not blocked due to resource consumption.

There are some other specific components for which no requests and limits were added, but their overall usage is not considerable in order to create a real difference in any kind of cluster configuration.

This MR is also connected to: !6381 and !6416

Related to issue #616

Relates to epic sylva-projects#102

Test coverage

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	`light-deploy`, `dev-sources`, `ha`, `misc`, `maxsurge-0`, `logging`, `no-logging`, `cilium`
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment (i.e `real-bmh` for capm3 )

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited Mar 03, 2026 by Thomas Morin

Add generic limits for the lacking components

What does this MR do and why?

Related reference(s)

Test coverage

CI configuration

Global config for deployment pipelines

Merge request reports