• Installation and Deployment

  • The minimum supported version that LogScale can be upgraded from has increased from 1.112 to 1.136. This change allows for removal of some obsolete data from LogScale database.

  • The Kafka client has been upgraded to 3.9.0.

• Installation and Deployment

  • The JDK has been upgraded to 23.0.1

• Upgrades

  • Bundled JDK is now upgraded to Java 23.

• Installation and Deployment

  • The JDK has been upgraded to 23.0.1

  • Upgraded the Kafka clients to 3.8.0.

• Upgrades

  • Bundled JDK is now upgraded to Java 23.

• Installation and Deployment

  • Upgraded the Kafka clients to 3.8.0.

• Installation and Deployment

  • The minimum version of Java compatible with LogScale is now 21. Docker users, and users installing the release artifacts that bundle the JDK, are not affected.

    It is recommended to switch to the release artifacts that bundle a JDK, because LogScale no longer supports bringing your own JDK as of release 1.138, see Falcon LogScale 1.138.0 GA (2024-05-14)

• Installation and Deployment

  • The minimum version of Java compatible with LogScale is now 21. Docker users, and users installing the release artifacts that bundle the JDK, are not affected.

    It is recommended to switch to the release artifacts that bundle a JDK, because LogScale no longer supports bringing your own JDK as of release 1.138, see Falcon LogScale 1.138.0 GA (2024-05-14)

• Installation and Deployment

  • The bundled JDK is upgraded to 22.0.2.

• Installation and Deployment

  • The minimum version of Java compatible with LogScale is now 21. Docker users, and users installing the release artifacts that bundle the JDK, are not affected.

    It is recommended to switch to the release artifacts that bundle a JDK, because LogScale no longer supports bringing your own JDK as of release 1.138, see Falcon LogScale 1.138.0 GA (2024-05-14)

• Installation and Deployment

  • The bundled JDK is upgraded to 22.0.2.

  • The Kafka client has been upgraded to 3.7.0. The Kafka server version in the deprecated humio/kafka Docker image is also upgraded to 3.7.0.

  • Bundled JDK upgraded to 22.0.1.

• Installation and Deployment

  • The Kafka client has been upgraded to 3.7.0. The Kafka server version in the deprecated humio/kafka Docker image is also upgraded to 3.7.0.

  • Bundled JDK upgraded to 22.0.1.

• Installation and Deployment

  • Bundled JDK upgraded to 22.0.1.

• Installation and Deployment

  • The Kafka client has been upgraded to 3.7.0. The Kafka server version in the deprecated humio/kafka Docker image is also upgraded to 3.7.0.

• Storage

  • Docker images have been upgraded to Java 22.

  • Added new deployment artifacts. The published tarballs (e.g. server.tar.gz) are now available with a bundled JDK. The platforms currently supported are linux_x64 for 64-bit Linux, and alpine_x64 for 64-bit Alpine Linux and other musl-based Linux distributions. The Docker images have been updated to use this bundled JDK internally. We encourage users to migrate to using the tarballs with bundled JDKs.

• Storage

  • Docker images have been upgraded to Java 22.

  • Added new deployment artifacts. The published tarballs (e.g. server.tar.gz) are now available with a bundled JDK. The platforms currently supported are linux_x64 for 64-bit Linux, and alpine_x64 for 64-bit Alpine Linux and other musl-based Linux distributions. The Docker images have been updated to use this bundled JDK internally. We encourage users to migrate to using the tarballs with bundled JDKs.

• Storage

  • Docker images have been upgraded to Java 22.

  • Added new deployment artifacts. The published tarballs (e.g. server.tar.gz) are now available with a bundled JDK. The platforms currently supported are linux_x64 for 64-bit Linux, and alpine_x64 for 64-bit Alpine Linux and other musl-based Linux distributions. The Docker images have been updated to use this bundled JDK internally. We encourage users to migrate to using the tarballs with bundled JDKs.

• Installation and Deployment

  • Kafka client library has been upgraded to 3.6.1. Some minor changes have been made to serializers used by LogScale to reduce memory copying.

• Installation and Deployment

  • Kafka client library has been upgraded to 3.6.1. Some minor changes have been made to serializers used by LogScale to reduce memory copying.

• Installation and Deployment

  • Kafka client library has been upgraded to 3.6.1. Some minor changes have been made to serializers used by LogScale to reduce memory copying.

• Installation and Deployment

  • Kafka client library has been upgraded to 3.6.1. Some minor changes have been made to serializers used by LogScale to reduce memory copying.

• Configuration

  • We've migrated from Akka dependency component to Apache Pekko. This means that all internal logs referencing Akka will be substituted with the Pekko counterpart. Users will need to update any triggers or dashboards that rely on such logs.

    On Prem only: be aware that the Akka to Pekko migration also affects configuration field names in application.conf. Clusters that are using a custom application.conf will need to update their configuration to use the Pekko configuration names instead of the Akka configuration names.

• Configuration

  • We've migrated from Akka dependency component to Apache Pekko. This means that all internal logs referencing Akka will be substituted with the Pekko counterpart. Users will need to update any triggers or dashboards that rely on such logs.

    On Prem only: be aware that the Akka to Pekko migration also affects configuration field names in application.conf. Clusters that are using a custom application.conf will need to update their configuration to use the Pekko configuration names instead of the Akka configuration names.

• Configuration

  • We've migrated from Akka dependency component to Apache Pekko. This means that all internal logs referencing Akka will be substituted with the Pekko counterpart. Users will need to update any triggers or dashboards that rely on such logs.

    On Prem only: be aware that the Akka to Pekko migration also affects configuration field names in application.conf. Clusters that are using a custom application.conf will need to update their configuration to use the Pekko configuration names instead of the Akka configuration names.

• Configuration

  • We've migrated from Akka dependency component to Apache Pekko. This means that all internal logs referencing Akka will be substituted with the Pekko counterpart. Users will need to update any triggers or dashboards that rely on such logs.

    On Prem only: be aware that the Akka to Pekko migration also affects configuration field names in application.conf. Clusters that are using a custom application.conf will need to update their configuration to use the Pekko configuration names instead of the Akka configuration names.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Configuration

  • Docker containers have been upgraded to Java 21.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Configuration

  • Docker containers have been upgraded to Java 21.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Configuration

  • Docker containers have been upgraded to Java 21.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Configuration

  • Docker containers have been upgraded to Java 21.

• Upgrades

  • This release introduces a change to the internal storage format use for sharing globsl data. Once upgraded to v1.112 or higher it will not be possible to downgrade to a version lower than 1.112.

• Configuration

  • Docker containers have been upgraded to Java 21.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Installation and Deployment

  • Permit running LogScale on Java 20. Docker containers have been upgraded to be based on Java 20.

• Other

  • The Kafka client has been upgraded to 3.4.1. The Kafka broker has been upgraded to 3.4.1 in the Kafka container.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Installation and Deployment

  • Permit running LogScale on Java 20. Docker containers have been upgraded to be based on Java 20.

• Other

  • The Kafka client has been upgraded to 3.4.1. The Kafka broker has been upgraded to 3.4.1 in the Kafka container.

• Installation and Deployment

  • Permit running LogScale on Java 20. Docker containers have been upgraded to be based on Java 20.

• Other

  • The Kafka client has been upgraded to 3.4.1. The Kafka broker has been upgraded to 3.4.1 in the Kafka container.

• Installation and Deployment

  • Permit running LogScale on Java 20. Docker containers have been upgraded to be based on Java 20.

• Other

  • The Kafka client has been upgraded to 3.4.1. The Kafka broker has been upgraded to 3.4.1 in the Kafka container.

• Other

  • The Kafka client has been upgraded to 3.4.1. The Kafka broker has been upgraded to 3.4.1 in the Kafka container.

• Installation and Deployment

  • Permit running LogScale on Java 20. Docker containers have been upgraded to be based on Java 20.

• Security

  • xmlsec has been upgraded to 2.3.4 to address CVE-2023-44483 issue.

• Other

  • Docker images have been upgraded to Java 19.0.2. to address CVE-2022-45688 issue.

  • Snakeyamls has been upgraded to 2.0 to address CVE-2022-1471 issue.

• Other

  • Docker images have been upgraded to Java 19.0.2. to address CVE-2022-45688 issue.

  • Snakeyamls has been upgraded to 2.0 to address CVE-2022-1471 issue.

• Other

  • Docker images have been upgraded to Java 19.0.2. to address CVE-2022-45688 issue.

  • Snakeyamls has been upgraded to 2.0 to address CVE-2022-1471 issue.

• Other

  • Snakeyamls has been upgraded to 2.0 to address CVE-2022-1471 issue.

• Other

  • OpenSSL in Docker images has been upgraded to address CVE-2023-0286 issue.

• Other

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

• Other

  • Java upgraded to 17.0.6 in Docker containers

    Kafka upgraded to 3.3.2 for KAFKA-14379

    Kafka client upgraded to 3.3.2

    Kafka Docker container upgraded to 3.3.2

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

• Packages

  • Optimizations in package handling require migration of data during upgrade. This migration is performed automatically. Please notice:

    • While the upgrade of cluster nodes are ongoing, we recommend you do not install or update any packages, as they may end up in an inconsistent state.

      If a package ends up in a bad state during migration, it can be fixed simply by reinstalling the package.

    • You will potentially experience that accessing the list of installed packages will fail, and creating new dashboards, alerts, parsers, etc. based on package templates will not work as intended.

      This should only happen during the cluster upgrade, and should resolve itself once the cluster is fully upgraded.

    • If the cluster nodes are downgraded, any packages installed or updated while running the new version will not work, and we therefore recommend uninstalling or downgrading those packages prior to downgrading the cluster nodes.

• Other

  • Java upgraded to 17.0.6 in Docker containers

    Kafka upgraded to 3.3.2 for KAFKA-14379

    Kafka client upgraded to 3.3.2

    Kafka Docker container upgraded to 3.3.2

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

• Packages

  • Optimizations in package handling require migration of data during upgrade. This migration is performed automatically. Please notice:

    • While the upgrade of cluster nodes are ongoing, we recommend you do not install or update any packages, as they may end up in an inconsistent state.

      If a package ends up in a bad state during migration, it can be fixed simply by reinstalling the package.

    • You will potentially experience that accessing the list of installed packages will fail, and creating new dashboards, alerts, parsers, etc. based on package templates will not work as intended.

      This should only happen during the cluster upgrade, and should resolve itself once the cluster is fully upgraded.

    • If the cluster nodes are downgraded, any packages installed or updated while running the new version will not work, and we therefore recommend uninstalling or downgrading those packages prior to downgrading the cluster nodes.

• Other

  • Java upgraded to 17.0.6 in Docker containers

    Kafka upgraded to 3.3.2 for KAFKA-14379

    Kafka client upgraded to 3.3.2

    Kafka Docker container upgraded to 3.3.2

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

• Packages

  • Optimizations in package handling require migration of data during upgrade. This migration is performed automatically. Please notice:

    • While the upgrade of cluster nodes are ongoing, we recommend you do not install or update any packages, as they may end up in an inconsistent state.

      If a package ends up in a bad state during migration, it can be fixed simply by reinstalling the package.

    • You will potentially experience that accessing the list of installed packages will fail, and creating new dashboards, alerts, parsers, etc. based on package templates will not work as intended.

      This should only happen during the cluster upgrade, and should resolve itself once the cluster is fully upgraded.

    • If the cluster nodes are downgraded, any packages installed or updated while running the new version will not work, and we therefore recommend uninstalling or downgrading those packages prior to downgrading the cluster nodes.

• Other

  • Java upgraded to 17.0.6 in Docker containers

    Kafka upgraded to 3.3.2 for KAFKA-14379

    Kafka client upgraded to 3.3.2

    Kafka Docker container upgraded to 3.3.2

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

• Packages

  • Optimizations in package handling require migration of data during upgrade. This migration is performed automatically. Please notice:

    • While the upgrade of cluster nodes are ongoing, we recommend you do not install or update any packages, as they may end up in an inconsistent state.

      If a package ends up in a bad state during migration, it can be fixed simply by reinstalling the package.

    • You will potentially experience that accessing the list of installed packages will fail, and creating new dashboards, alerts, parsers, etc. based on package templates will not work as intended.

      This should only happen during the cluster upgrade, and should resolve itself once the cluster is fully upgraded.

    • If the cluster nodes are downgraded, any packages installed or updated while running the new version will not work, and we therefore recommend uninstalling or downgrading those packages prior to downgrading the cluster nodes.

• Other

  • Java upgraded to 17.0.6 in Docker containers

    Kafka upgraded to 3.3.2 for KAFKA-14379

    Kafka client upgraded to 3.3.2

    Kafka Docker container upgraded to 3.3.2

• Packages

  • Optimizations in package handling require migration of data during upgrade. This migration is performed automatically. Please notice:

    • While the upgrade of cluster nodes are ongoing, we recommend you do not install or update any packages, as they may end up in an inconsistent state.

      If a package ends up in a bad state during migration, it can be fixed simply by reinstalling the package.

    • You will potentially experience that accessing the list of installed packages will fail, and creating new dashboards, alerts, parsers, etc. based on package templates will not work as intended.

      This should only happen during the cluster upgrade, and should resolve itself once the cluster is fully upgraded.

    • If the cluster nodes are downgraded, any packages installed or updated while running the new version will not work, and we therefore recommend uninstalling or downgrading those packages prior to downgrading the cluster nodes.

• Other

  • Java upgraded to 17.0.6 in Docker containers

    Kafka upgraded to 3.3.2 for KAFKA-14379

    Kafka client upgraded to 3.3.2

    Kafka Docker container upgraded to 3.3.2

• Packages

  • Optimizations in package handling require migration of data during upgrade. This migration is performed automatically. Please notice:

    • While the upgrade of cluster nodes are ongoing, we recommend you do not install or update any packages, as they may end up in an inconsistent state.

      If a package ends up in a bad state during migration, it can be fixed simply by reinstalling the package.

    • You will potentially experience that accessing the list of installed packages will fail, and creating new dashboards, alerts, parsers, etc. based on package templates will not work as intended.

      This should only happen during the cluster upgrade, and should resolve itself once the cluster is fully upgraded.

    • If the cluster nodes are downgraded, any packages installed or updated while running the new version will not work, and we therefore recommend uninstalling or downgrading those packages prior to downgrading the cluster nodes.

• Installation and Deployment

  • We have enabled a new vhost selection method by default. The way hosts select their vhost number when joining the cluster has changed, the new logic is described at Node Identifiers documentation page.

    The new logic does not depend on ZooKeeper, even for clusters where nodes occasionally lose disk contents, such as Kubernetes. In order to smooth migration for clusters using ZooKeeper, the new logic will still interact with ZooKeeper to avoid nodes using a mix of new and old vhost code from fighting over the vhost numbers. This is only necessary while migrating.

    The recommended steps for migrating off of ZooKeeper are as follows:

    1. Deploy the new LogScale version to all nodes.

    2. Remove ZOOKEEPER_URL_FOR_NODE_UUID, ZOOKEEPER_URL, ZOOKEEPER_PREFIX_FOR_NODE_UUID, ZOOKEEPER_SESSIONTIMEOUT_FOR_NODE_UUID from the configuration for all nodes.

    3. Reboot

    Once rebooted, LogScale will no longer need ZooKeeper directly, except as an indirect dependency of Kafka. Due to this, the 4 ZooKeeper-related variables are deprecated as of this release and will be removed in a future version.

    Since vhost numbers now change when a disk is wiped, cluster administrators for clusters using nodes where USING_EPHEMERAL_DISKS is set to true will need to ensure that the storage and digest partitioning tables are up to date as hosts join and leave the cluster. Updating the tables is handled automatically if using the LogScale Kubernetes operator, but for clusters that do not use this operator, cluster administrators should run scripts periodically to keep the storage and digest tables up to date. This is not a new requirement for ephemeral clusters, but we're providing a reminder here since it may be needed more frequently now.

    The cluster GraphQL query can provide updated tables (the suggestedIngestPartitions and suggestedStoragePartitions fields), which can then be applied via the updateIngestPartitionScheme and updateStoragePartitionScheme GraphQL mutations.

    Should you experience any issue in using this feature, you may opt out by setting NEW_VHOST_SELECTION_ENABLED=false. If you do this, please reach out to support with feedback, as we otherwise intend to remove the old vhost selection logic in the coming months.

    Note

    When using Operator and Kubernetes deployments, you must upgrade to 0.17.0 of operator to support migration away from the ZooKeeper requirement. See Operator Version 0.17.0.

• Other

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

• Installation and Deployment

  • We have enabled a new vhost selection method by default. The way hosts select their vhost number when joining the cluster has changed, the new logic is described at Node Identifiers documentation page.

    The new logic does not depend on ZooKeeper, even for clusters where nodes occasionally lose disk contents, such as Kubernetes. In order to smooth migration for clusters using ZooKeeper, the new logic will still interact with ZooKeeper to avoid nodes using a mix of new and old vhost code from fighting over the vhost numbers. This is only necessary while migrating.

    The recommended steps for migrating off of ZooKeeper are as follows:

    1. Deploy the new LogScale version to all nodes.

    2. Remove ZOOKEEPER_URL_FOR_NODE_UUID, ZOOKEEPER_URL, ZOOKEEPER_PREFIX_FOR_NODE_UUID, ZOOKEEPER_SESSIONTIMEOUT_FOR_NODE_UUID from the configuration for all nodes.

    3. Reboot

    Once rebooted, LogScale will no longer need ZooKeeper directly, except as an indirect dependency of Kafka. Due to this, the 4 ZooKeeper-related variables are deprecated as of this release and will be removed in a future version.

    Since vhost numbers now change when a disk is wiped, cluster administrators for clusters using nodes where USING_EPHEMERAL_DISKS is set to true will need to ensure that the storage and digest partitioning tables are up to date as hosts join and leave the cluster. Updating the tables is handled automatically if using the LogScale Kubernetes operator, but for clusters that do not use this operator, cluster administrators should run scripts periodically to keep the storage and digest tables up to date. This is not a new requirement for ephemeral clusters, but we're providing a reminder here since it may be needed more frequently now.

    The cluster GraphQL query can provide updated tables (the suggestedIngestPartitions and suggestedStoragePartitions fields), which can then be applied via the updateIngestPartitionScheme and updateStoragePartitionScheme GraphQL mutations.

    Should you experience any issue in using this feature, you may opt out by setting NEW_VHOST_SELECTION_ENABLED=false. If you do this, please reach out to support with feedback, as we otherwise intend to remove the old vhost selection logic in the coming months.

    Note

    When using Operator and Kubernetes deployments, you must upgrade to 0.17.0 of operator to support migration away from the ZooKeeper requirement. See Operator Version 0.17.0.

• Installation and Deployment

  • We have enabled a new vhost selection method by default. The way hosts select their vhost number when joining the cluster has changed, the new logic is described at Node Identifiers documentation page.

    The new logic does not depend on ZooKeeper, even for clusters where nodes occasionally lose disk contents, such as Kubernetes. In order to smooth migration for clusters using ZooKeeper, the new logic will still interact with ZooKeeper to avoid nodes using a mix of new and old vhost code from fighting over the vhost numbers. This is only necessary while migrating.

    The recommended steps for migrating off of ZooKeeper are as follows:

    1. Deploy the new LogScale version to all nodes.

    2. Remove ZOOKEEPER_URL_FOR_NODE_UUID, ZOOKEEPER_URL, ZOOKEEPER_PREFIX_FOR_NODE_UUID, ZOOKEEPER_SESSIONTIMEOUT_FOR_NODE_UUID from the configuration for all nodes.

    3. Reboot

    Once rebooted, LogScale will no longer need ZooKeeper directly, except as an indirect dependency of Kafka. Due to this, the 4 ZooKeeper-related variables are deprecated as of this release and will be removed in a future version.

    Since vhost numbers now change when a disk is wiped, cluster administrators for clusters using nodes where USING_EPHEMERAL_DISKS is set to true will need to ensure that the storage and digest partitioning tables are up to date as hosts join and leave the cluster. Updating the tables is handled automatically if using the LogScale Kubernetes operator, but for clusters that do not use this operator, cluster administrators should run scripts periodically to keep the storage and digest tables up to date. This is not a new requirement for ephemeral clusters, but we're providing a reminder here since it may be needed more frequently now.

    The cluster GraphQL query can provide updated tables (the suggestedIngestPartitions and suggestedStoragePartitions fields), which can then be applied via the updateIngestPartitionScheme and updateStoragePartitionScheme GraphQL mutations.

    Should you experience any issue in using this feature, you may opt out by setting NEW_VHOST_SELECTION_ENABLED=false. If you do this, please reach out to support with feedback, as we otherwise intend to remove the old vhost selection logic in the coming months.

    Note

    When using Operator and Kubernetes deployments, you must upgrade to 0.17.0 of operator to support migration away from the ZooKeeper requirement. See Operator Version 0.17.0.

• Other

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

• Other

  • Kafka client has been upgraded to 3.4.0.

    Kafka broker has been upgraded to 3.4.0 in the Kafka container.

    The container upgrade is performed for security reasons to resolve CVE-2022-36944 issue, which Kafka should however not be affected by. If you wish to do a rolling upgrade of your Kafka containers, please always refer to Kafka upgrade guide.

The table below shows the list of LogScale versions and the minimum version from which you can upgrade.