SD Elements 2025.2

What’s new?

New Reporting Service Container

The internal architecture of the reporting service has been changed to implement the new Cube JS dependency Cube Store. The container can be found in the reporting pod with the name {RELEASE_NAME}-reporting-cubestore.

$ kubectl get pod -l name=sde-reporting -o custom-columns=NAMESPACE:.metadata.namespace,POD_NAME:.metadata.name,CONTAINER_NAME:.spec.containers[*].name -n {NAMESPACE}
NAMESPACE   POD_NAME                         CONTAINER_NAME
sde         sde-reporting-##########-#####   sde-reporting-nginx,sde-reporting,sde-reporting-cubestore

No additional configuration is required. The implementation of Cube Store does not change SD Elements functionality. Its implementation was driven by our continued commitment to keeping SD Elements and its dependencies updated.

Read more about Cube Store here: Introducing Cube Store

New Kubernetes Cronjobs

The export-artifact-cleanup and export-job-cleanup cronjobs have been added to the SD Elements by default on a schedule of daily and hourly, respectively.

No additional configuration is required.

Database TLS Support

Previously, SD Elements supported TLS connections with its database only when using a customer-managed database configured with a certificate issued by a public certificate authority. As of 2025.2 all customers may optionally configure database TLS connections for the bundled database service and customer-managed databases, using self-signed certificates or that which is issued through public or private certificate authorities.

See the (Optional) Enabling TLS section for details on configuring database TLS communication.

AWS Role Authentication (Object Storage)

Authentication with AWS S3 via IAM Roles is now supported in addition to access key based authentication.

See IAM Role Authentication for details on configuring IAM Roles in the Helm chart.

Upgrading to 2025.2

Known Issues

Upgrade Duration

SD Elements 2025.2 improves the Activity Log feature of the application, significantly improving performance for all customers. During upgrades to 2025.2, SD Elements will automatically perform a an intra-database migration to move existing activity logs to a new database table. No additional action is needed to enable the migration, and it cannot be excluded from the upgrade.

Instances with a large number of activity logs will require more time to complete the upgrade. We’ve provided some guidelines in the Evaluate Required Disk Performance section to help you plan your upgrade and maintenance window.

Database Storage

A patch will be available on August 2nd which will tune default configurations and add support for overriding defaults in the custom values file.

As mentioned above, the reporting service will now use the Cube Store container in the reporting pod for trend reporting instead of Redis in older SD Elements version. Trends are calculated using data snapshots created by the Cube Store container.

The default snapshot frequency and retention may, in some cases, produce steep increases in storage requirements after upgrade. The exact increase is determined by:

  • Dataset size

  • User traffic on UI

  • System-to-system traffic (API-based system integrations, issue trackers, etc.)

Security Compass strongly recommends ensuring a maximum of 50% disk utilization (ideal 33%) and that alerts are in place to notify administrators of high disk utilization.

Prerequisites

  • Evaluate required disk performance

  • Ensure sufficient free disk space for database

Evaluate Required Disk Performance

If you have not already, please review the Upgrade Duration section in Known Issues before proceeding.

The intra-database migration for the improved Activity Log feature requires read and write operations to move existing activity logs to a new table. As such, database volume performance will directly influence the duration of the overall upgrade.

While we’d love to have a formula we can share that calculates the 'right' disk performance for our customers, variability in SD Elements data composition and underlying hardware makes this infeasible. Instead, we’ve provided this section to guide you to a decision that balances the tradeoff between time and any costs from more performant storage.

First, follow the steps in the Retrieve Activity Logs Record Count section to get a total count of activity logs in your SD Elements instance. Instances with under 10 million activity logs are expected to complete with minimal additional downtime required. If your instance has over 10 million activity logs, we recommend our customers consider temporarily increases database disk performance for the upgrade.

For an idea of potential upgrade durations, see the SaaS Upgrade Benchmarks section below.

Retrieve Activity Logs Record Count

Option 1 (API Request):

The activity log record count is provided in the count key of the /activities endpoint response. Documentation covering authenticating with the SD Elements API can be found here.

Request: GET /api/v2/activities/?page_size=1

Response:

{
    "count": 123456,
    "next": "https://cd.sdelements.com/api/v2/activities/?page=2&page_size=1",
    "previous": null,
    "results": [
        ...
    ]
}

Option 2 (SQL Query):

Open a shell into the database pod and run the query below to retrieve a total count of activity log records.

The value passed to the '-U' option should match postgresql.auth.username. The example below uses the default database user, sde.
$ kubectl exec -n sde --stdin --tty sde-database-0 -c postgresql -- /bin/bash
www-data@sde-database-0:/$ psql -d sdelements -U sde
psql (16.4)
Type "help" for help.

sdelements=# SELECT count(*) as activity_count FROM public.activity_activitymodel WHERE v2_enabled = false;
 activity_count
----------------
          ##,###
(1 row)
SaaS Upgrade Benchmarks

For the 2025.2 upgrade in the SD Elements SaaS environment we increased the database disk’s performance for a select number of our customers with over 12 million activity logs.

Activity Log Count Disk Configuration Upgrade Duration

<12 million

  • AWS EBS, GP3

  • 3,000 IOPS (default)

  • 125MB/s throughput (default)

6 hours

>=12 million

  • AWS EBS, GP3

  • 16,000 IOPS (↑)

  • 125MB/s throughput (default)

13 hours (total)

The majority of SaaS instances were upgraded in less than 6 hours as upgrades are performed in groups.

Steps

Follow the general upgrade notes here.

results matching ""

    No results matching ""