Manage App Framework polling
Configure App Framework polling and manual update triggers.
Control how the App Framework manages app updates by configuring the polling behavior, turning off automatic polling, and manually triggering app updates. You can prevent the App Framework from automatically polling the remote storage for app changes and instead manually trigger app updates when desired.
Turn off automatic polling
To turn off App Framework automatic polling of the remote storage for app changes, set the appsRepoPollIntervalSeconds setting to 0. This configuration stops the App Framework from periodically checking for app updates and updates the configMap with a new status field.
appsRepoPollIntervalSeconds: 0
Manually trigger app checks
When you are ready to initiate an app check, manually update the status field in the configMap. The status field defaults to off.
Namespace-specific ConfigMap
The primary configMap used for manual updates is namespace-specific. For example, if you deploy a Standalone Custom Resource (CR) with the App Framework enabled, the Splunk Operator creates a configMap named splunk-default-manual-app-update (assuming the default namespace).
Example Standalone CR deployment:
kubectl get standalone
NAME PHASE DESIRED READY AGE
s1 Ready 1 1 13h
Generated namespace-specific ConfigMap:
apiVersion: v1
data:
Standalone: |-
status: off
refCount: 1
kind: ConfigMap
metadata:
creationTimestamp: "2021-08-24T01:04:01Z"
name: splunk-manual-app-update
namespace: default
ownerReferences:
- apiVersion: enterprise.splunk.com/v3
controller: false
kind: Standalone
name: s1
uid: ddb9528f-2e25-49be-acd4-4fadde489849
resourceVersion: "75406013"
selfLink: /api/v1/namespaces/default/configmaps/splunk-manual-app-update
uid: 413c6053-af4f-4cb3-97e0-6dbe7cd17721
To trigger a manual app check, update the status field to on:
kubectl patch cm/splunk-default-manual-app-update --type merge -p '{"data":{"Standalone":"status: on\nrefCount: 1"}}'
The App Framework performs its checks, updates or installs apps as necessary, and resets the status to off upon completion.
Per custom resource ConfigMap
In addition to the namespace-specific configMap, the system also supports a configMap per custom resource. This provides finer control over app updates for individual CRs.
ConfigMap naming convention:
splunk-<namespace>-<custom-resource-name>-configmap
Behavior:
- When a custom resource is created, a corresponding
configMapis automatically created alongside other resources. - The system first checks the namespace-specific
configMap(splunk-default-manual-app-update). - If manual updates are not enabled in the namespace-specific
configMap, the system checks the per CRconfigMapfor the manualUpdate field. - If
manualUpdate: trueis set in the per CRconfigMap, the App Framework performs the app check and resets the field tomanualUpdate: falseafter completing the task. - For Indexer Cluster updates, use the Cluster Manager configmap. You cannot use the individual Indexer Cluster configmap for manual app updates.
Example per CR ConfigMap:
apiVersion: v1
data:
manualUpdate: "true"
kind: ConfigMap
metadata:
name: splunk-default-s1-configmap
namespace: default
ownerReferences:
- apiVersion: enterprise.splunk.com/v3
controller: true
kind: Standalone
name: s1
uid: ddb9528f-2e25-49be-acd4-4fadde489849
To trigger a manual app check for a specific custom resource, update the manualUpdate field to true:
kubectl patch cm/splunk-default-s1-configmap --type merge -p '{"data":{"manualUpdate":"true"}}'
The App Framework performs the necessary app checks and resets manualUpdate to false once completed.
Reinstate automatic polling
To enable automatic polling again, update the CR appsRepoPollIntervalSeconds setting to a value greater than 0.
appsRepoPollIntervalSeconds: 60
Important considerations
- Consistency across CRs: All CRs of the same type within a namespace must have polling either enabled or turned off uniformly. For example, if appsRepoPollIntervalSeconds is set to
0for one Standalone CR, all other Standalone CRs in the same namespace must also have polling turned off. - Avoid mixed configurations: Using a mix of enabled and turned-off polling across CRs of the same type can lead to unexpected behavior. Use the kubectl command to identify and ensure consistent polling configurations across all CRs before making changes.
- Namespace and CR-specific configuration: The system prioritizes the namespace-specific
configMapfor manual updates. If not enabled, the system falls back to the per CRconfigMap. This hierarchical approach ensures that manual updates can be managed both at the namespace level and for individual resources as needed.