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.

Note: The App Framework still performs an initial poll of the remote storage even when polling is turned off upon CR initialization.
CODE
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:

CODE
kubectl get standalone
NAME   PHASE   DESIRED   READY   AGE
s1     Ready   1         1       13h

Generated namespace-specific ConfigMap:

CODE
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:

JSON
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:

CODE
splunk-<namespace>-<custom-resource-name>-configmap

Behavior:

  • When a custom resource is created, a corresponding configMap is 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 CR configMap for the manualUpdate field.
  • If manualUpdate: true is set in the per CR configMap, the App Framework performs the app check and resets the field to manualUpdate: false after 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:

CODE
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:

JSON
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.

CODE
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 0 for 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 configMap for manual updates. If not enabled, the system falls back to the per CR configMap. This hierarchical approach ensures that manual updates can be managed both at the namespace level and for individual resources as needed.