Features, limitations, and known issues with DG Operator 8.3.x

Environment

• Red Hat Data Grid (RHDG)
  • 8.x
  • Dg Operator 8.3.x vs 8.2.x

Issue

What are the known issues with DG Operator 8.3.x?

Resolution

As the main recommendation do not install an old version of the DG Operator, install the latest, the following issues were diagnosed on DG Operator 8.3.x:

DG Operator 8.3.6:

DG Operator 8.3.7:

DG Operator 8.3.8:

For more issues, see solution Issues with Data Grid Operator 8.3.8.

DG Operator 8.3.x vs 8.2.x: comparative

Using a different version of DG 8 and DG Operator

By setting the spec.image in the Custom Resource one can overwrite the default version of DG 8 - which fetches DG 8 image directly. However, this is unsupported though, given the DG Operator will bring a specific version already.
But this can be useful for instance in case of adding jcmd on the default image for instance - where the DG 8 image still the default.

Cache Creation [warning]

At this point, there is no warning on wrong configuration of caches, so the caches will be created and the status - will be there and the (wrongful configured) cache will not turn "Ready". Therefore verify the cache template creation, the namespace, the Infinispan's cluster name and the configuration set there:
Also when creating caches and batches, make sure to process templates and apply yamls.

Invalidation cache will fail

Although in DG CLI the cache creation succeeds, in the Operator (via cache yaml) Invalidation cache creation will fail, since there is no valid use-case for invalidation-cache for server inside OCP environment. See more details on Data Grid Invalidation cache on server/client mode. Below cache creation will fail and it is expected to fail:

  spec:
    clusterName: ${CLUSTER_NAME}
    name:  operator-cache-98
    template: |
      invalidationCache:
        locking:
          acquireTimeout: "15000"
          concurrencyLevel: "1000"
          striping: "false"

Cross-site change

As explained on Gossip Router pod in DG 8 OCP 4, DG Operator 8.3.x uses GossipRouter pod, where it needs only one Gossip Router pod to nominally operate and if one of the sites crashes, it uses the other site GossipRouter via tunnel protocol - following the diagram shows Tunnel protocol usage:

custer1Node -> cluster1Master -> GossipRouter -> cluster2Master -> cluster2OtherNode
which is the same as:
cluster1Node -> cluster1Relay1 -> GossipRouter -> cluster1Relay2 -> cluster2OtherNode

Memory requirement changes:

There was an increased the default Memory requirements from 512Mi -> 1Gi as the old value only provided a very small amount of memory that could be utilized as a cache when the overhead of the server and JVM was taken into account. See Content from github.com is not included.Operator 1386

Deprecated type Cache

As explained on Deprecated service type Cache in DG 8 in OCP 4, the spec.service.type.Cache is deprecated and should be avoided, use instead type DataGrid. However, it is the default (spec.service.type default is Cache). This is to maintain backwards compatibility on upgrades from other versions. Also note the Cache type will use as GC collector SerialGC, same as the Gossip Router pod.

Console Web

In order for the console to be accessible one need to explicitly expose the svc via a Route or LoadBalancer, regardless of what service type is used - nodePort leads to continuous loading:

    expose:
      type: LoadBalancer

Diagnostic Steps

For diagnosing issues:

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.