Further changes

splunk · Nov 21, 2024 · 17a7bc2 · 17a7bc2
1 parent ab2acb4
commit 17a7bc2
Show file tree

Hide file tree

Showing 8 changed files with 47 additions and 120 deletions.
diff --git a/bundle/manifests/splunk-operator.clusterserviceversion.yaml b/bundle/manifests/splunk-operator.clusterserviceversion.yaml
@@ -111,7 +111,7 @@ metadata:
     capabilities: Seamless Upgrades
     categories: Big Data, Logging & Tracing, Monitoring, Security, AI/Machine Learning
     containerImage: splunk/splunk-operator@sha256:c4e0d314622699496f675760aad314520d050a66627fdf33e1e21fa28ca85d50
-    createdAt: "2024-11-21T20:21:20Z"
+    createdAt: "2024-11-21T21:00:57Z"
     description: The Splunk Operator for Kubernetes enables you to quickly and easily
       deploy Splunk Enterprise on your choice of private or public cloud provider.
       The Operator simplifies scaling and management of Splunk Enterprise by automating
@@ -120,7 +120,7 @@ metadata:
     operators.operatorframework.io/builder: operator-sdk-v1.31.0
     operators.operatorframework.io/project_layout: go.kubebuilder.io/v3
     repository: https://github.com/splunk/splunk-operator
-  name: splunk-operator.v2.6.1
+  name: splunk-operator.v2.7.0
   namespace: placeholder
 spec:
   apiservicedefinitions: {}
@@ -671,4 +671,4 @@ spec:
   - image: docker.io/splunk/splunk:9.3.2
     name: splunk-enterprise
   replaces: splunk-operator.v2.6.0
-  version: 2.6.1
+  version: 2.7.0
diff --git a/config/manifests/bases/splunk-operator.clusterserviceversion.yaml b/config/manifests/bases/splunk-operator.clusterserviceversion.yaml
@@ -12,7 +12,7 @@ metadata:
       administrative workflows using Kubernetes best practices.
     olm.properties: '[{"type": "olm.maxOpenShiftVersion", "value": "4.15"}]'
     repository: https://github.com/splunk/splunk-operator
-  name: splunk-operator.v2.6.1
+  name: splunk-operator.v2.7.0
   namespace: placeholder
 spec:
   apiservicedefinitions: {}
@@ -274,5 +274,5 @@ spec:
   provider:
     name: Splunk Inc.
     url: www.splunk.com
-  replaces: splunk-operator.v2.6.0
-  version: 2.6.1
+  replaces: splunk-operator.v2.6.1
+  version: 2.7.0
diff --git a/docs/AppFramework.md b/docs/AppFramework.md
@@ -689,7 +689,7 @@ spec:
         - name: OPERATOR_NAME
           value: "splunk-operator"
         - name: RELATED_IMAGE_SPLUNK_ENTERPRISE
-          value: "docker.io/splunk/splunk:9.1.3"
+          value: "docker.io/splunk/splunk:9.3.2"
 
       volumes:
       - name: app-staging

diff --git a/docs/ChangeLog-NEW.md b/docs/ChangeLog-NEW.md
diff --git a/docs/ChangeLog.md b/docs/ChangeLog.md
@@ -1,5 +1,39 @@
 # Splunk Operator for Kubernetes Change Log
 
+## 2.7.0 (2024-12-04)
+
+* This is the 2.7.0 release. The Splunk Operator for Kubernetes is a supported platform for deploying Splunk Enterprise with the prerequisites and constraints laid out [here](https://github.com/splunk/splunk-operator/blob/main/docs/README.md#prerequisites-for-the-splunk-operator)
+
+* CPSL-2699 - Add Azure and GCP SDK support for AppFramework
+
+* CSPL-3149 - Address openshift documentation for 4.14 or later
+
+* CSPL-3060 - Avoid upgrade path during deployment creation
+
+* CSPL-3058 - Build docker image using SHA instead of tag for redhat UBI
+
+* CSPL-3063 - Add an option to test SVA testing only via helm
+
+* CSPL-2496  - Cleanup AWS resources during cluster cleanup
+
+* CSPL-2887 - Update eksctl, K8s versions, default storage class
+
+* CSPL-2756 - Add documentation for PDB with SOK deployments
+
+* CSPL-2820 - Add Support for Configuring Custom Cluster Domain in Helm Chart
+
+### Supported Splunk Version
+
+>| Splunk Version|
+>| --- |
+>| 9.3.2 |
+
+### Supported Kubernetes Version
+
+>| Kubernetes Version|
+>| --- |
+>| 1.31+ |
+
 ## 2.6.1 (2024-08-27)
 
 * This is the 2.6.1 release. The Splunk Operator for Kubernetes is a supported platform for deploying Splunk Enterprise with the prerequisites and constraints laid out [here](https://github.com/splunk/splunk-operator/blob/main/docs/README.md#prerequisites-for-the-splunk-operator)

diff --git a/docs/Install.md b/docs/Install.md
@@ -31,7 +31,7 @@ If Splunk Operator is installed clusterwide and user wants to manage multiple na
         - name: WATCH_NAMESPACE
           value: "namespace1,namespace2"
         - name: RELATED_IMAGE_SPLUNK_ENTERPRISE
-          value: splunk/splunk:9.1.3
+          value: splunk/splunk:9.3.2
         - name: OPERATOR_NAME
           value: splunk-operator
         - name: POD_NAME
@@ -68,7 +68,7 @@ If you are using a private registry for the Docker images, edit `deployment` `sp
         - name: WATCH_NAMESPACE
           value: "namespace1,namespace2"
         - name: RELATED_IMAGE_SPLUNK_ENTERPRISE
-          value: splunk/splunk:9.1.3
+          value: splunk/splunk:9.3.2
         - name: OPERATOR_NAME
           value: splunk-operator
         - name: POD_NAME

diff --git a/docs/MultisiteExamples.md b/docs/MultisiteExamples.md
@@ -148,7 +148,7 @@ metadata:
   - enterprise.splunk.com/delete-pvc
 spec:
   replicas: 3
-  image: "splunk/splunk:9.1.3"
+  image: "splunk/splunk:9.3.2"
   clusterManagerRef:
     name: example
   defaults: |-

diff --git a/docs/SplunkOperatorUpgrade.md b/docs/SplunkOperatorUpgrade.md
@@ -48,7 +48,7 @@ If a Splunk Operator release changes the custom resource (CRD) API version, the
 
 ### Upgrading Splunk Enterprise Docker Image with the Operator Upgrade
 
-Splunk Operator follows the upgrade path steps mentioned in [Splunk documentation](https://docs.splunk.com/Documentation/Splunk/9.1.3/Installation/HowtoupgradeSplunk). If a Splunk Operator release includes an updated Splunk Enterprise Docker image, the operator upgrade will also initiate pod restart using the latest Splunk Enterprise Docker image. To follow the best practices described under the [General Process to Upgrade the Splunk Enterprise], a recommeded upgrade path is followed while initiating pod restarts of different Splunk Instances. At each step, if a particular CR instance exists, a certain flow is imposed to ensure that each instance is updated in the correct order. After an instance is upgraded, the Operator verifies if the upgrade was successful and all the components are working as expected. If any unexpected behaviour is detected, the process is terminated.
+Splunk Operator follows the upgrade path steps mentioned in [Splunk documentation](https://docs.splunk.com/Documentation/Splunk/9.3.2/Installation/HowtoupgradeSplunk). If a Splunk Operator release includes an updated Splunk Enterprise Docker image, the operator upgrade will also initiate pod restart using the latest Splunk Enterprise Docker image. To follow the best practices described under the [General Process to Upgrade the Splunk Enterprise], a recommeded upgrade path is followed while initiating pod restarts of different Splunk Instances. At each step, if a particular CR instance exists, a certain flow is imposed to ensure that each instance is updated in the correct order. After an instance is upgraded, the Operator verifies if the upgrade was successful and all the components are working as expected. If any unexpected behaviour is detected, the process is terminated.
 
 If a Splunk Operator release changes the custom resource (CRD) API version, the administrator is responsible for updating their Custom Resource specification to reference the latest CRD API version.
 
@@ -104,7 +104,7 @@ Edit `deployment` `splunk-operator-controller-manager-<podid>` in `splunk-operat
         - name: WATCH_NAMESPACE
           value: "splunk-operator"
         - name: RELATED_IMAGE_SPLUNK_ENTERPRISE
-          value: splunk/splunk:9.1.3
+          value: splunk/splunk:9.3.2
         - name: OPERATOR_NAME
           value: splunk-operator
         - name: POD_NAME
@@ -139,7 +139,7 @@ To verify that a new Splunk Enterprise Docker image was applied to a pod, you ca
 
 ```bash
 kubectl get pods splunk-<crname>-monitoring-console-0 -o yaml | grep -i image
-image: splunk/splunk:9.1.3
+image: splunk/splunk:9.3.2
 imagePullPolicy: IfNotPresent
 ```
 ## Splunk Enterprise Cluster upgrade