What’s new in 8.3.7.

Disabling FIPS mode

You can disable FIPS mode in your Infinispan CR, so that any component that uses a JVM can ignore FIPS mode. This means that your Data Grid instance can run on any OpenShift cluster that has FIPS mode enabled.

Enhanced bidirectional reconciliation

Data Grid Operator 8.3.7 improves the bidirectional reconciliation mechanism, so that it includes idempotent creation and retrieval capabilities. The idempotent capability aligns bidirectional reconciliation with Kubernetes conventions.

See Resource reconciliation (Data Grid Operator)

Updated cluster view response

The Data Grid Operator 8.3.7 can now updates the status field to False when it cannot create a cache from a Cache custom resource (CR).

Validating and mutating webhooks

Data Grid Operator 8.3.7 includes validating and mutating webhooks. A webhook changes the behavior of the Kubernetes API, so that this API can immediately reject any CR with invalid specifications.

What’s new in 8.3.4.

Hot Rod rolling upgrades with Data Grid Operator

From version 8.3.4 onward, you can upgrade Data Grid clusters when new versions become available without service downtime and data loss. The shutdown upgrade remains the default upgrade type. For information on how to enable Hot Rod rolling upgrades see Upgrading Data Grid clusters.

User-defined annotations for created resources

This release introduces configurable annotations that you can use to organize and monitor Data Grid resources.

Performance improvement that avoids unnecessary iptable rules

The Data Grid Operator endpoint is now available as a headless service. Headless services avoid the creation of several iptable rules that can impact the performance of the cluster.

OpenShift route as a expose type for cross-site replication

This release lets you use OpenShift Route as a new expose type for cross-site replication. You can use an OpenShift Route to handle network traffic for backup operations between Data Grid clusters.

Data Grid Operator resource reconciliation

Data Grid Operator 8.3.4 introduces bidirectional reconciliation that enables syncing Data Grid caches with OpenShift Custom Resource (CR) definitions. Bidirectional reconciliation synchronizes your CRs with changes that you make to Data Grid resources through the Data Grid Console, command line interface (CLI), or other client application and vice versa.

To perform bidirectional reconciliation, you must have configListener enabled in the Data Grid service.

Configuration enhancements

When configuring cross-site replication, you no longer need to specify locations in the Data Grid CR. Data Grid Operator configures Data Grid services without site locations configured.

What’s new in 8.3.1.

Updated OpenShift bundle for Data Grid Operator deployments

The OpenShift bundle for Data Grid Operator deployments includes images built with OpenJDK 11 to support multiple system architectures including:

For more information see Java Change in Power and Z OpenShift Images.

Enhancements to memory and CPU requests and limits

This release increases the default values for memory and CPU resources that Data Grid Operator requests from the OpenShift scheduler when creating Data Grid pods.

Additionally you can now allocate resources in the format of <limit>:<requests> in your Infinispan CR as follows:

spec:
  container:
    cpu: "2000m:1000m"
    memory: "2Gi:1Gi"

Readiness and liveness probes updated for better performance

Settings for the readiness and liveness probes are updated so that Data Grid clusters become available sooner.

What’s new in 8.3 GA.

Numerous improvements to the Data Grid Operator code base

The Data Grid team have invested a lot of time and effort into internal improvements to the Data Grid Operator code base to enable future enhancements.

Full support for native CLI installation and operation

To improve the installation and operation experience, Data Grid 8.3 offers full support for the native CLI as an oc client plugin. Installing the native CLI extends your oc client with the following commands:

Custom Data Grid Server configuration

You can now add Data Grid Server configuration to a ConfigMap and make it available to Data Grid Operator. Data Grid Operator can then apply the custom configuration to your Data Grid cluster.

Configurable number of relay nodes for cross-site replication

Data Grid clusters now use router pods, which are GossipRouter instances, to coordinate RELAY messages for cross-site replication. You can also configure the number of pods in each cluster that can send RELAY messages to router pods with the sites.local.maxRelayNodes field.

TLS security for cross-site connections

Add keystores, and optional trust stores, to encrypt RELAY messages and secure cross-site replication traffic between Data Grid clusters.

Cache service type deprecation

The Cache service type was designed to provide a convenient way to create a low-latency data store with minimal configuration. Additional development on the Infinispan CRD has shown that the Cache CR offers a better approach to achieving this goal, ultimately giving users more choice and less deployment overhead. For this reason, the Cache service type is planned for removal in the next version of the Infinispan CRD and is no longer under active development.

Red Hat recommends configuring the DataGrid service type for clusters. The DataGrid service type continues to benefit from new features and improved tooling to automate complex operations such as cluster upgrades and data migration.

You can create DataGrid service clusters as follows:

The following table provides detailed version information for Data Grid Operator.

This section describes issues that affect Data Grid clusters that you manage with Data Grid Operator. For complete details about Data Grid, you should refer to the Data Grid 8.3 release notes.

Description: If out of memory exceptions cause Data Grid Server to terminate on OpenShift, unexpected behavior can occur. In some cases nodes cannot restart and the org.infinispan.LOCKS enters degraded mode. The following exception is written to the pod log file:

FATAL (main) [org.infinispan.SERVER] ISPN080028: Red Hat Data Grid Server failed to start java.util.concurrent.ExecutionException: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.LOCKS on <pod-name-id>

Workaround: There is no workaround for this issue. You should configure eviction in Data Grid caches to help avoid OOM exceptions.

Data Grid Operator 8.3.0 includes the following notable fixes:

Data Grid Operator 8.3.1 includes the following notable fixes:

Data Grid Operator 8.3.4 includes the following notable fixes:

Data Grid Operator 8.3.6 includes the following notable fixes:

Data Grid Operator 8.3.7 includes the following notable fixes:

Data Grid 8.3 includes two container images, the Data Grid Operator image and Data Grid Server image.

Data Grid images are hosted on the Red Hat Container Registry, where you can find health indexes for the images along with information about each tagged version.

Custom Data Grid Deployments

Red Hat does not support customization of any 8.3 images from the Red Hat Container Registry through the Source-to-Image (S2I) process or ConfigMap API.

As a result it is not possible to use custom:

Using embedded Data Grid caches in applications running on OpenShift, which was referred to as Library Mode in previous releases, is intended for specific uses only:

Red Hat supports only DNS_PING as the cluster discovery mechanism.

DNS_PING exposes a port named ping that Data Grid nodes use to perform discovery and join clusters. TCP is the only supported protocol for the ping port, as in the following example for a pod on OpenShift:

spec:
  ...
  ports:
    - name: ping
      port: 8888
      protocol: TCP
      targetPort: 8888