You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/AppFramework.md
+91-11Lines changed: 91 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -568,19 +568,37 @@ spec:
568
568
```
569
569
570
570
571
-
## Manual initiation of app management
572
-
You can prevent the App Framework from automatically polling the remote storage for app changes. By configuring the `appsRepoPollIntervalSeconds` setting to `0`, the App Framework polling is disabled, and the configMap is updated with a new `status` field. The App Framework will perform an initial poll of the remote storage, even when the CR is initialized with polling disabled.
571
+
## Manual Initiation of App Management
573
572
574
-
When you're ready to initiate an app check using the App Framework, manually update the `status` field in the configMap for that CR type to `on`. The 'status' field defaults to 'off'.
573
+
You can control how the App Framework manages app updates by configuring the polling behavior. This allows you to prevent the App Framework from automatically polling the remote storage for app changes and instead manually trigger app updates when desired.
575
574
576
-
For example, you deployed one Standalone CR with app framework enabled.
575
+
### Disabling Automatic Polling
577
576
577
+
To disable the App Framework's 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.
578
+
579
+
**Note:** The App Framework will still perform an initial poll of the remote storage even when polling is disabled upon CR initialization.
580
+
581
+
```yaml
582
+
appsRepoPollIntervalSeconds: 0
578
583
```
584
+
585
+
### Manual Triggering of App Checks
586
+
587
+
When you are ready to initiate an app check using the App Framework, you need to manually update the `status` field in the `configMap`. The `status` field defaults to `off`.
588
+
589
+
#### Namespace-Specific ConfigMap
590
+
591
+
The primary `configMap` used for manual updates is namespace-specific. For example, if you have deployed a Standalone Custom Resource (CR) with the App Framework enabled, the Splunk Operator will create a `configMap` named `splunk-default-manual-app-update` (assuming the `default` namespace).
592
+
593
+
##### Example Standalone CR Deployment
594
+
595
+
```bash
579
596
kubectl get standalone
580
597
NAME PHASE DESIRED READY AGE
581
598
s1 Ready 1 1 13h
582
599
```
583
-
As mentioned above, Splunk Operator will create the configMap (assuming `default` namespace) `splunk-default-manual-app-update` with an entry for Standalone CR as below:
The App Framework will perform its checks, update or install apps as necessary, and reset the `status` to `off` upon completion.
632
+
633
+
#### Per Custom Resource ConfigMap
634
+
635
+
In addition to the namespace-specific `configMap`, the system now supports a `configMap` per custom resource. This provides finer control over app updates for individual CRs.
1. **Creation:** When a custom resource is created, a corresponding `configMap` is automatically created alongside other resources.
646
+
647
+
2. **Manual Update Check:**
648
+
- The system first checks the namespace-specific `configMap` (`splunk-default-manual-app-update`).
649
+
- If manual updates are not enabled in the namespace-specific `configMap`, it then checks the per CR `configMap` for the `manualUpdate` field.
650
+
- 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.
651
+
652
+
**Example Per CR ConfigMap:**
653
+
654
+
```yaml
655
+
apiVersion: v1
656
+
data:
657
+
manualUpdate: "true"
658
+
kind: ConfigMap
659
+
metadata:
660
+
name: splunk-default-s1-configmap
661
+
namespace: default
662
+
ownerReferences:
663
+
- apiVersion: enterprise.splunk.com/v3
664
+
controller: true
665
+
kind: Standalone
666
+
name: s1
667
+
uid: ddb9528f-2e25-49be-acd4-4fadde489849
668
+
```
669
+
670
+
To trigger a manual app check for a specific custom resource, update the `manualUpdate` field to `true`:
- **Consistency Across CRs:** All CRs of the same type within a namespace must have polling either enabled or disabled 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 disabled.
689
+
690
+
- **Avoid Mixed Configurations:** Using a mix of enabled and disabled 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.
610
691
611
-
The App Framework will perform its checks, update or install apps, and reset the `status` to `off` when it has completed its tasks.
692
+
- **Namespace and CR-Specific Configuration:** The system prioritizes the namespace-specific `configMap` for manual updates. If it is not enabled, it 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.
612
693
613
-
To reinstate automatic polling, update the CR `appsRepoPollIntervalSeconds` setting to a value greater than 0.
694
+
By following these guidelines, you can effectively manage when and how the App Framework checks for and applies app updates, providing both broad and granular control over your application environment.
614
695
615
-
NOTE: All CRs of the same type must have polling enabled, or disabled. For example, if `appsRepoPollIntervalSeconds` is set to '0' for one Standalone CR, all other Standalone CRs must also have polling disabled. Use the `kubectl` command to identify all CRs of the same type before updating the polling interval. You can experience unexpected polling behavior if there are CRs configured with a mix of polling enabled and disabled.
0 commit comments