Applier configuration
The purpose of this topic is to list and describe the additional parameters available for configuring the StormForge Applier. For parameters that apply to the StormForge Agent, see the Agent configuration topic.
Applier settings:
Continuous reconciliation
Controls resource patching behavior based on CI/CD and cluster activity. Auto-deployment must be enabled.
Parameter | Default value |
---|---|
reconciliation.mode |
EventBased |
reconciliation.conflictingManagers |
None |
Description
The StormForge Applier can be configured to continuously reconcile drift, ensuring that the latest recommended settings are always maintained on a workload.
The Applier logs whenever it reconciles a workload’s resource settings to the recommended values.
Valid values
-
EventBased
(default): Workload requests and limits are updated only by relevant StormForge events that trigger an update: autodeployment of a new recommendation, clicking Apply Now in the UI, or runningstormforge apply
. Subsequent updates to requests and limits by GitOps tools will override the recommended settings. -
Continuous
: recommended requests and limits values are maintained and not overwritten during CI/CD or deployment activity on the cluster, except when changes are made by the declaredreconciliation.conflictingManagers
.reconciliation.conflictingManagers
: Optional, honored only whenreconciliation.mode=Continuous
. Declares which field managers conflict with the Applier. The Applier will not reconcile the desired state for fields owned by conflicting managers. Use this if you cannot configure your existing field manager to accept or ignore changes from StormForge.
Installing on Red Hat OpenShift
Required only when installing the Applier on Red Hat OpenShift.
Parameter | Default value |
---|---|
openshift |
false |
Description
Set to true
when installing the StormForge Applier on Red Hat OpenShift Container Platform version 4.x and later. See this guide for details.
Valid values
Any positive Kubernetes quantity, appropriate to the resource. Examples:
true
false
(default)
Additional RBAC permission
A YAML manifest that grants additional RBAC permissions to the Applier.
Description
To optimize resources that that are not Kubernetes workload types, the Applier needs additional RBAC permissions on the API group and resources.
Example
Add the API groups and their resources in a YAML manifest (for example, applier-rbac.yaml
) as shown below.
A working example is shown in the Rightsize workloads scaled by a KEDA-owned HPA topic.
rbac:
additional: |-
# In this section, add any resources that you want the Applier to patch
- apiGroups:
- # YOUR_API_GROUP
resources:
- # YOUR_RESOURCES
verbs:
- get
- list
- watch
- patch
- update