Release 2.2.0 and 2.2.1

SUMMARY.md

@@ -123,10 +123,12 @@
   * [E-mail notifications](setup/configure-stackstate/email-notifications.md)
   * [Stackpacks](stackpacks/about-stackpacks.md)
 * [Release Notes](setup/release-notes/README.md)
-  * [v2.0.0 - 11/09/2024](setup/release-notes/20240911112250.md)
-  * [v2.0.1 - 18/09/2024](setup/release-notes/20240918082712.md)
-  * [v2.0.2 - 01/10/2024](setup/release-notes/20241001154902.md)
-  * [v2.1.0 - 29/10/2024](setup/release-notes/20241023133226.md)
+  * [v2.0.0 - 11/09/2024](setup/release-notes/v2.0.0.md)
+  * [v2.0.1 - 18/09/2024](setup/release-notes/v2.0.1.md)
+  * [v2.0.2 - 01/10/2024](setup/release-notes/v2.0.2.md)
+  * [v2.1.0 - 29/10/2024](setup/release-notes/v2.1.0.md)
+  * [v2.2.0 - 09/12/2024](setup/release-notes/v2.2.0.md)
+  * [v2.2.1 - 10/12/2024](setup/release-notes/v2.2.1.md)
 * [Upgrade SUSE Observability](setup/upgrade-stackstate/README.md)
   * [Migration from StackState](setup/upgrade-stackstate/migrate-from-6.md)
   * [Steps to upgrade](setup/upgrade-stackstate/steps-to-upgrade.md)
@@ -144,6 +146,7 @@
 * [Security](setup/security/README.md)
   * [Authentication](setup/security/authentication/README.md)
     * [Authentication options](setup/security/authentication/authentication_options.md)
+    * [Single password](/setup/security/authentication/single_password.md)
     * [File-based](setup/security/authentication/file.md)
     * [LDAP](setup/security/authentication/ldap.md)
     * [Open ID Connect \(OIDC\)](setup/security/authentication/oidc.md)
@@ -155,6 +158,7 @@
     * [Roles](setup/security/rbac/rbac_roles.md)
     * [Scopes](setup/security/rbac/rbac_scopes.md)
   * [Self-signed certificates](setup/security/self-signed-certificates.md)
+  * [External secrets](setup/security/external-secrets.md)
 
 
 ## 🔐 Security

k8s-suse-rancher-prime.md

@@ -158,7 +158,12 @@ The `sizing.profile` should be one of trial, 10-nonha, 20-nonha, 50-nonha, 100-n
 This command will generate a `$VALUES_DIR/suse-observability-values/templates/baseConfig_values.yaml` and a `$VALUES_DIR/suse-observability-values/templates/sizing_values.yaml` file which contains the necessary configuration for installing the SUSE Observability Helm Chart.
 
 {% hint style="info" %}
-The SUSE Observability administrator passwords will be autogenerated by the above command and are output as comments in the generated `basicConfig.yaml` file. The actual values contain the `bcrypt` hashes of those passwords so that they're securely stored in the Helm release in the cluster.
+The SUSE Observability administrator password will be autogenerated by the above command and are output as comments in the generated `basicConfig.yaml` file. For more info, see [single password](/setup/security/authentication/single_password.md).
+The actual values contain the `bcrypt` hashes of those passwords so that they're securely stored in the Helm release in the cluster.
+{% endhint %}
+
+{% hint style="warn" %}
+Using a single default password is great to get started with SUSE Observability, but for a production setup [more secure authentication options](/setup/security/authentication/authentication_options.md) are available.
 {% endhint %}
 
 {% hint style="info" %}

setup/configure-stackstate/email-notifications.md

@@ -16,21 +16,30 @@ SUSE Observability needs to be configured with credentials to connect to the SMT
 
 ```yaml
 stackstate:
-  components:
-    all:
-      extraEnv:
-        open:
-          CONFIG_FORCE_stackstate_email_sender: "<stackstate@example.com>"
-          CONFIG_FORCE_stackstate_email_server_host: "<smtp.example.com>"
-          CONFIG_FORCE_stackstate_email_server_username: "<user name>"
-        secret:
-          CONFIG_FORCE_stackstate_email_server_password: "<user password>"
+  email:
+    enabled: true
+    sender: "<stackstate@example.com>"
+    server:
+      host: "<smtp.example.com>"
+      auth:
+        username: "<user name>"
+        password: "<user password>"
 ```
 
-This will use port `587` on the SMTP server and uses the `STARTTLS` command to establish a secure connection.
-To use a different port, it can be specified explicitly:
+This will use port `587` on the SMTP server and uses the `STARTTLS` command to establish a secure connection. These are all the other options that can be customized:
 
 ```yaml
-stackstate.components.all.extraEnv.open:
-  CONFIG_FORCE_stackstate_email_server_port: 465
+stackstate:
+  email:
+    additionalProperties: 
+      # Add needed Java email properties for your mail server (use string values), defaults are: 
+      "mail.smtp.auth": "true"
+      "mail.smtp.starttls.enable": "true"
+    server:
+      protocol: smtp
+      port: 587
 ```
+
+### Using an external secret
+
+When the username and password cannot be provided in the values but should come from an external secret, follow [these steps](/setup/security/external-secrets.md#getting-username-and-password-for-email-sending-from-an-external-secret)

setup/data-management/data_retention.md

@@ -10,45 +10,29 @@ SUSE Observability imposes data retention limits to save storage space and impro
 
 ## Retention of topology graph data
 
-By default, topology graph data will be retained for 30 days. This works in a way that the latest state of topology graph will always be retained; only history older than 30 days will be removed. You can check and alter the configured retention period this using the SUSE Observability CLI.
+By default, topology graph data will be retained for 30 days. This works in a way that the latest state of topology graph will always be retained; only history older than 30 days will be removed.
+In some cases, it may be useful to keep historical data for more than 30 days or to reduce it to less than 30 days to save on disk space. Topology retention can be configured through the helm chart:
 
-```shell
-$ sts graph retention
-```
-
-In some cases, it may be useful to keep historical data for more than 30 days or to reduce it to less than 30 days to save on disk space.
-
-```shell
-$ sts graph retention --set 10d
-```
-
-\(note that the duration can be specified as a duration string\)
-
-Note that by adding more time to the data retention period, the amount of data stored is also going to grow and need more storage space. This may also affect the performance of the Views.
-
-After changing the retention period to a smaller window, you may end up with some data that's already expired and will wait there until the next scheduled cleanup. To schedule a cleanup soon after the new retention window is applied use this command:
-
-```shell
-$ sts graph retention --set 10d --schedule-removal
+```yaml
+stackstate:
+  topology:
+    # Retention set to 1 week
+    retentionHours: 144
 ```
 
-In some cases, for example a disk running full, it can be needed to force removal of data immediately. This will have an impact on performance and current activity on SUSE Observability so is better avoided. 
+Note that by adding more time to the data retention period, the amount of data stored is also going to grow and requires more storage space. This may also affect the performance of the Views.
 
-Note that this may take some time to have an effect.
+When lowering the retention period, it can take some time until disk space is freed up (at least 15 minutes).
 
-```shell
-$ sts graph delete-expired-data --immediately
-```
-
-## Retention of events, traces and logs
+## Retention of events and logs
 
 ### SUSE Observability data store
 
 If you are using the event/logs store provided with SUSE Observability, your data will by default be retained for 30 days. In most cases, the default settings will be sufficient to store all indices for this amount of time.
 
 #### Configure disk space for Elasticsearch
 
-In some circumstances it may be necessary to adjust the disk space available to Elasticsearch and how it's allocated to logs, events and traces, for example if you anticipate a lot of data to arrive for a specific data type. 
+In some circumstances it may be necessary to adjust the disk space available to Elasticsearch and how it's allocated to logs and events, for example if you anticipate a lot of data to arrive for a specific data type. 
 
 Here is a snippet with the complete disk space and retention config for Elasticsearch, including the default values.
 
@@ -68,11 +52,6 @@ stackstate:
       esDiskSpaceShare: 30
       # Number of days to keep the events data on Es
       retention: 30
-    trace2es:
-      esDiskSpaceShare: 0
-      # Number of days to keep the traces data on Es
-      retention: 7
-      enabled: false
 ```
 
 The disk space available for Elasticsearch is configured via the `elasticsearch.volumeClaimTemplate.resources.requests.storage` key. To change this value after the initial installation some [extra steps are required](data_retention.md#resizing-storage).

setup/install-stackstate/kubernetes_openshift/ingress.md

@@ -72,6 +72,20 @@ opentelemetry-collector:
       - hosts:
           - otlp-stackstate.MY_DOMAIN
         secretName: otlp-tls-secret
+    additionalIngresses:
+      - name: otlp-http
+        annotations:
+          nginx.ingress.kubernetes.io/proxy-body-size: "50m"
+        hosts:
+          - host: otlp-http-stackstate.MY_DOMAIN        
+            paths:
+              - path: /
+                pathType: Prefix
+                port: 4318
+        tls:
+          - hosts:
+            - otlp-http-stackstate.MY_DOMAIN        
+              secretName: otlp-http-tls-secret        
 ```
 
 The thing that stands out in this file is the Nginx annotation to increase the allowed `proxy-body-size` to `50m` \(larger than any expected request\). By default, Nginx allows body sizes of maximum `1m`. SUSE Observability Agents and other data providers can sometimes send much larger requests. For this reason, you should make sure that the allowed body size is large enough, regardless of whether you are using Nginx or another ingress controller. Make sure to update the `baseUrl` in the values file generated during initial installation, it will be used by SUSE Observability to generate convenient installation instructions for the agent.

setup/install-stackstate/kubernetes_openshift/kubernetes_install.md

@@ -81,7 +81,6 @@ The values that can be passed to this chart are:
 | Base URL | `baseUrl` | The `<STACKSTATE_BASE_URL>`. The external URL for SUSE Observability that users and agents will use to connect. For example `https://suse-observability.internal`. If you haven't decided on an Ingress configuration yet, use `http://localhost:8080`. This can be updated later in the generated file.                                                                                                    |
 | Username and password\*\* | `-u` `-p` | The username and password used by SUSE Observability to pull images. For air-gapped environments these need to be the username and password for the local contaier registry. |
 | License key | `license` | The SUSE Observability license key. |
-| Admin API password | `adminApiPassword` | The password for the admin API. Note that this API contains system maintenance functionality and should only be accessible by the maintainers of the SUSE Observability installation. If you omit this, a random password will be generated for you. If you do pass this value and it's not bcrypt hashed, the chart will hash it for you. |
 | Default password | `adminPassword` | The password for the default user \(`admin`\) to access SUSE Observability's UI. If you omit this, a random password will be generated for you. If you do pass this value and it's not bcrypt hashed, the chart will hash it for you.|
 | Image Registry | `imageRegistry` | The registry where the SUSE Observability images are hosted. If not provided, the default value will be 'quay.io' |
 | Pull Secret Username | `pullSecret.username` | The username used to pull images from the Docker registry where the SUSE Observability images are hosted. Only needed for custom registries. |

setup/install-stackstate/kubernetes_openshift/openshift_install.md

@@ -87,7 +87,6 @@ The values that can be passed to this chart are:
 | Base URL | `baseUrl` | The `<STACKSTATE_BASE_URL>`. The external URL for SUSE Observability that users and agents will use to connect. For example `https://suse-observability.internal`. If you haven't decided on an Ingress configuration yet, use `http://localhost:8080`. This can be updated later in the generated file.                                                                                                    |
 | Username and password\*\* | `-u` `-p` | The username and password used by SUSE Observability to pull images. For air-gapped environments these need to be the username and password for the local docker registry. |
 | License key | `license` | The SUSE Observability license key. |
-| Admin API password | `adminApiPassword` | The password for the admin API. Note that this API contains system maintenance functionality and should only be accessible by the maintainers of the SUSE Observability installation. If you omit this, a random password will be generated for you. If you do pass this value and it's not bcrypt hashed, the chart will hash it for you. |
 | Default password | `adminPassword` | The password for the default user \(`admin`\) to access SUSE Observability's UI. If you omit this, a random password will be generated for you. If you do pass this value and it's not bcrypt hashed, the chart will hash it for you.|
 | Image Registry | `imageRegistry` | The registry where the SUSE Observability images are hosted. If not provided, the default value will be 'quay.io' |
 | Pull Secret Username | `pullSecret.username` | The username used to pull images from the Docker registry where the SUSE Observability images are hosted. |

setup/install-stackstate/kubernetes_openshift/storage.md

@@ -21,21 +21,8 @@ For the `size` we provide the sameple for both `HA` and `NonHa` depending on the
 {% tab title="Changing storage class" %}
 ```yaml
 global:
-  # The storage class for most of the persistent volumes
+  # The storage class for all of the persistent volumes
   storageClass: "standard"
-
-elasticsearch:
-  volumeClaimTemplate:
-    storageClassName: "standard"
-
-victoria-metrics-0:
-  server:
-    persistentVolume:
-      storageClass: "standard"
-victoria-metrics-1:
-  server:
-    persistentVolume:
-      storageClass: "standard"
 ```
 {% endtab %}
 

setup/otel/collector.md

@@ -34,7 +34,7 @@ To install and configure the collector for usage with SUSE Observability we'll u
 ### Configure the collector
 
 Here is the full values file needed, continue reading below the file for an explanation of the different parts. Or skip ahead to the next step, but make sure to replace:
-* `<otlp-stackstate-endpoint>` with the OTLP endpoint of your SUSE Observability. If, for example, you access SUSE Observability on `play.stackstate.com` the OTLP endpoint is `otlp-play.stackstate.com`. So simply prefixing `otlp-` to the normal SUSE Observability url will do.
+* `<otlp-stackstate-endpoint>` with the OTLP endpoint of your SUSE Observability. If, for example, you access SUSE Observability on `play.stackstate.com` the OTLP endpoint is `otlp-play.stackstate.com` for GRPC and `otlp-http-play.stackstate.com` for  HTTP traffic. So simply prefixing `otlp-` or `otlp-http-` to the normal SUSE Observability url will do.
 * `<your-cluster-name>` with the cluster name you configured in SUSE Observability. **This must be the same cluster name used when installing the SUSE Observability agent**. Using a differnt cluster name will result in an empty traces perspective for Kubernetes components.
 
 {% hint style="warning" %}
@@ -68,6 +68,10 @@ config:
       auth:
         authenticator: bearertokenauth
       endpoint: <otlp-stackstate-endpoint>:443
+    otlphttp/stackstate:
+       auth:
+          authenticator: bearertokenauth
+       endpoint: https://<otlp--http-stackstate-endpoint>      
   processors:
     tail_sampling:
       decision_wait: 10s
@@ -161,7 +165,7 @@ The `service` section determines what components of the collector are enabled. T
 The `pipelines` section defines pipelines for the traces and metrics. The metrics pipeline defines:
 * `receivers`, to receive metrics from instrumented applications (via the OTLP protocol, `otlp`), from spans (the `spanmetrics` connector) and by scraping Prometheus endpoints (the `prometheus` receiver). The latter is configured by default in the collector Helm chart to scrape the collectors own metrics
 * `processors`: The `memory_limiter` helps to prevent out-of-memory errors. The `batch` processor helps better compress the data and reduce the number of outgoing connections required to transmit the data. The `resource` processor adds additional resource attributes (discussed separately)
-* `exporters`: The `debug` exporter simply logs to stdout which helps when troubleshooting. The `otlp/stackstate` exporter sends telemetry data to SUSE Observability using the OTLP protocol. It is configured to use the bearertokenauth extension for authentication to send data to the SUSE Observability OTLP endpoint.
+* `exporters`: The `debug` exporter simply logs to stdout which helps when troubleshooting. The `otlp/stackstate` exporter sends telemetry data to SUSE Observability using the OTLP protocol via GRPC (Default). The `otlphttp/stackstate` exporter sends telemetry data to SUSE Observability using the OTLP protocol via HTTP and is meant to be used where there area some impediments to use the GRPC one (needs to be activated in the pipelines). Both OTLP exporters are configured to use the bearertokenauth extension for authentication to send data to the SUSE Observability OTLP endpoint.
 
 For traces, there are 3 pipelines that are connected:
 * `traces`: The pipeline that receives traces from SDKs (via the `otlp` receiver) and does the initial processing using the same processors as for metrics. It exports into a router which routes all spans to both other traces pipelines. This setup makes it possible to calculate span metrics for all spans while applying sampling to the traces that are exported.

setup/otel/troubleshooting.md

@@ -36,14 +36,8 @@ To ensure the api key is configured correctly check that:
 
 ### Some proxies and firewalls don't work well with gRPC
 
-If the collector needs to send data through a proxy or a firewall it can be that they either block the traffic completely or possibly drop some parts of the gRPC messages or unexpectedly drop the long-lived gRPC connection completely. The easiest fix is to switch from gRPC to use HTTP instead, by replacing the `otlp/stackstate` exporter configuration and all its references with the  `otlp-http/stackstate` exporter with this configuration.
+If the collector needs to send data through a proxy or a firewall it can be that they either block the traffic completely or possibly drop some parts of the gRPC messages or unexpectedly drop the long-lived gRPC connection completely. The easiest fix is to switch from gRPC to use HTTP instead, by replacing the `otlp/stackstate` exporter configuration and all its references with the  `otlphttp/stackstate` exporter which is already configured and ready.
 
-```yaml
-    otlp-http/stackstate:
-      auth:
-        authenticator: bearertokenauth
-      endpoint: <otlp-http-stackstate-endpoint>:4318
-```
 
 Here `<otlp-http-stackstate-endpoint>` is similar to the `<otlp-stackstate-endpoint>`, but instead of a `otlp-` prefix it has `otlp-http-` prefix, for example, `otlp-http-play.stackstate.com`.