Procedure

1. Log in to the OpenShift Web Console.
2. Navigate to OperatorHub.
3. Find and select Data Grid Operator.
4. Select Install and continue to Create Operator Subscription.

5. Specify options for your subscription.

   Installation Mode

   You can install Data Grid Operator into a Specific namespace or All namespaces.

   Update Channel

   Get updates for Data Grid Operator 8.2.x.

   Approval Strategies

   Automatically install updates from the 8.2.x channel or require approval before installation.

6. Select Subscribe to install Data Grid Operator.
7. Navigate to Installed Operators to verify the Data Grid Operator installation.

Procedure

1. Set up projects.

   1. Create a project for Data Grid Operator.

   2. If you want Data Grid Operator to control a specific Data Grid cluster only, create a project for that cluster.

      $ oc new-project ${INSTALL_NAMESPACE} 1
      $ oc new-project ${WATCH_NAMESPACE} 2

      1

      Creates a project into which you install Data Grid Operator.

      2

      Optionally creates a project for a specific Data Grid cluster if you do not want Data Grid Operator to watch all projects.

2. Create an OperatorGroup resource.

   Control all Data Grid clusters

   $ oc apply -f - << EOF
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
    name: datagrid
    namespace: ${INSTALL_NAMESPACE}
   EOF

   Control a specific Data Grid cluster

   $ oc apply -f - << EOF
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
    name: datagrid
    namespace: ${INSTALL_NAMESPACE}
   spec:
    targetNamespaces:
    - ${WATCH_NAMESPACE}
   EOF

3. Create a subscription for Data Grid Operator.

   $ oc apply -f - << EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
    name: datagrid-operator
    namespace: ${INSTALL_NAMESPACE}
   spec:
    channel: 8.2.x
    installPlanApproval: Automatic
    name: datagrid
    source: redhat-operators
    sourceNamespace: openshift-marketplace
   EOF

   Note

   If you want to manually approve updates from the 8.2.x channel, change the value of the spec.installPlanApproval field to Manual.

4. Verify the installation.

   $ oc get pods -n ${INSTALL_NAMESPACE}
   NAME                                   READY   STATUS
   infinispan-operator-<id>               1/1     Running

Procedure

1. Specify the number of Data Grid pods in the cluster with spec.replicas in your Infinispan CR.

   For example, create a cr_minimal.yaml file as follows:

   $ cat > cr_minimal.yaml<<EOF
   apiVersion: infinispan.org/v1
   kind: Infinispan
   metadata:
     name: example-infinispan
   spec:
     replicas: 2
   EOF

2. Apply your Infinispan CR.

   $ oc apply -f cr_minimal.yaml

3. Watch Data Grid Operator create the Data Grid pods.

   $ oc get pods -w
   
   NAME                        READY  STATUS              RESTARTS   AGE
   example-infinispan-1        0/1    ContainerCreating   0          4s
   example-infinispan-2        0/1    ContainerCreating   0          4s
   example-infinispan-3        0/1    ContainerCreating   0          5s
   infinispan-operator-0       1/1    Running             0          3m
   example-infinispan-3        1/1    Running             0          8s
   example-infinispan-2        1/1    Running             0          8s
   example-infinispan-1        1/1    Running             0          8s

Procedure

1. Change the spec.replicas field to 0 to stop the Data Grid cluster.

   spec:
     replicas: 0

2. Ensure you have the correct number of pods before you restart the cluster.

   $ oc get infinispan example-infinispan -o=jsonpath='{.status.replicasWantedAtRestart}'

3. Change the spec.replicas field to the same number of pods to restart the Data Grid cluster.

   spec:
     replicas: 6

Procedure

1. Create an Infinispan CR that sets spec.service.type: DataGrid and configures any other Data Grid service resources.

   apiVersion: infinispan.org/v1
   kind: Infinispan
   metadata:
     name: example-infinispan
   spec:
     replicas: 2
     service:
       type: DataGrid

2. Apply your Infinispan CR to create the cluster.

Procedure

1. Create an Infinispan CR that sets spec.service.type: Cache and configures any other Cache service resources.

   apiVersion: infinispan.org/v1
   kind: Infinispan
   metadata:
     name: example-infinispan
   spec:
     replicas: 2
     service:
       type: Cache

2. Apply your Infinispan CR to create the cluster.

Procedure

1. Allocate storage resources with the spec.service.container.storage field.

2. Optionally configure the ephemeralStorage and storageClassName fields as required.

   spec:
     service:
       type: DataGrid
       container:
         storage: 2Gi
         ephemeralStorage: false
         storageClassName: my-storage-class

3. Apply the changes.

Procedure

1. Configure Data Grid logging with the spec.logging.categories field in your Infinispan CR.

   spec:
     logging:
       categories:
         org.infinispan: debug
         org.jgroups: debug

2. Apply the changes.

3. Retrieve logs from Data Grid pods as required.

   $ oc logs -f $POD_NAME

Procedure

1. Open your Infinispan CR for editing.
2. Add any labels that you want Data Grid Operator to attach to resources with metadata.annotations.

3. Add values for your labels with metadata.labels.

   1. Specify labels that you want to attach to services with the metadata.annotations.infinispan.org/targetLabels field.
   2. Specify labels that you want to attach to pods with the metadata.annotations.infinispan.org/podTargetLabels field.

   3. Define values for your labels with the metadata.labels fields.

      apiVersion: infinispan.org/v1
      kind: Infinispan
      metadata:
        annotations:
          infinispan.org/targetLabels: svc-label1, svc-label2
          infinispan.org/podTargetLabels: pod-label1, pod-label2
        labels:
          svc-label1: svc-value1
          svc-label2: svc-value2
          pod-label1: pod-value1
          pod-label2: pod-value2
          # The operator does not attach these labels to resources.
          my-label: my-value
          environment: development

4. Apply your Infinispan CR.

Procedure

1. Create an identities.yaml file with the credentials that you want to add.

   credentials:
   - username: myfirstusername
     password: changeme-one
   - username: mysecondusername
     password: changeme-two

2. Create an authentication secret from identities.yaml.

   $ oc create secret generic --from-file=identities.yaml connect-secret

3. Specify the authentication secret with spec.security.endpointSecretName in your Infinispan CR and then apply the changes.

   spec:
     security:
       endpointSecretName: connect-secret

Procedure

1. Set false as the value for the spec.security.endpointAuthentication field in your Infinispan CR.

   spec:
     security:
       endpointAuthentication: false

2. Apply the changes.

Procedure

1. Set either Validate or Authenticate as the value for the spec.security.endpointEncryption.clientCert field in your Infinispan CR.

   Note

   The default value is None.

2. Specify the secret that contains the client trust store with the spec.security.endpointEncryption.clientCertSecretName field.

   By default Data Grid Operator expects a trust store secret named <cluster-name>-client-cert-secret.

   Note

   The secret must be unique to each Infinispan CR instance in the OpenShift cluster. When you delete the Infinispan CR, OpenShift also automatically deletes the associated secret.

   spec:
     security:
       endpointEncryption:
           type: Service
           certSecretName: tls-secret
           clientCert: Validate
           clientCertSecretName: example-infinispan-client-cert-secret

3. Apply the changes.

Procedure

1. Specify the name of the secret that contains the client trust store as the value of the metadata.name field.

   Note

   The name must match the value of the spec.security.endpointEncryption.clientCertSecretName field.

2. Provide the password for the trust store with the stringData.truststore-password field.

3. Specify the trust store with the data.truststore.p12 field.

   apiVersion: v1
   kind: Secret
   metadata:
     name: example-infinispan-client-cert-secret
   type: Opaque
   stringData:
       truststore-password: changme
   data:
       truststore.p12:  "<base64_encoded_PKCS12_trust_store>"

4. Apply the changes.

Procedure

1. Specify the name of the secret that contains the client trust store as the value of the metadata.name field.

   Note

   The name must match the value of the spec.security.endpointEncryption.clientCertSecretName field.

2. Specify the signing certificate, or CA certificate bundle, as the value of the data.trust.ca field.

3. If you use the Authenticate strategy to verify client identities, add the certificate for each client that can connect to Data Grid endpoints with the data.trust.cert.<name> field.

   Note

   Data Grid Operator uses the <name> value as the alias for the certificate when it generates the trust store.

4. Optionally provide a password for the trust store with the stringData.truststore-password field.

   If you do not provide one, Data Grid Operator sets "password" as the trust store password.

   apiVersion: v1
   kind: Secret
   metadata:
     name: example-infinispan-client-cert-secret
   type: Opaque
   stringData:
       truststore-password: changme
   data:
       trust.ca: "<base64_encoded_CA_certificate>"
       trust.cert.client1: "<base64_encoded_client_certificate>"
       trust.cert.client2: "<base64_encoded_client_certificate>"

5. Apply the changes.

Procedure

1. Set None as the value for the spec.security.endpointEncryption.type field in your Infinispan CR.

   spec:
     security:
       endpointEncryption:
         type: None

2. Apply the changes.

Procedure

1. Add the encryption secret to your OpenShift namespace, for example:

   $ oc apply -f tls_secret.yaml

2. Specify the encryption secret with the spec.security.endpointEncryption.certSecretName field in your Infinispan CR.

   spec:
     security:
       endpointEncryption:
         type: Secret
         certSecretName: tls-secret

3. Apply the changes.

Procedure

1. Set true as the value for the spec.security.authorization.enabled field in your Infinispan CR.

   spec:
     security:
       authorization:
         enabled: true

2. Apply the changes.

Procedure

1. Create an identities.yaml file that assigns roles to users.

   credentials:
     - username: admin
       password: changeme
     - username: my-user-1
       password: changeme
       roles:
         - admin
     - username: my-user-2
       password: changeme
       roles:
         - monitor

2. Create an authentication secret from identities.yaml.

   If necessary, delete the existing secret first.

   $ oc delete secret connect-secret --ignore-not-found
   $ oc create secret generic --from-file=identities.yaml connect-secret

3. Specify the authentication secret with spec.security.endpointSecretName in your Infinispan CR and then apply the changes.

   spec:
     security:
       endpointSecretName: connect-secret

Procedure

1. Open your Infinispan CR for editing.

2. Specify custom roles and their associated permissions with the spec.security.authorization.roles field.

   spec:
     security:
       authorization:
         enabled: true
         roles:
           - name: my-role-1
             permissions:
               - ALL
           - name: my-role-2
             permissions:
               - READ
               - WRITE

3. Apply the changes.

Procedure

1. Include spec.expose in your Infinispan CR.
2. Specify LoadBalancer as the service type with the spec.expose.type field.

3. Optionally specify the network port where the service is exposed with the spec.expose.port field. The default port is 7900.

   spec:
     expose:
       type: LoadBalancer
       port: 65535

4. Apply the changes.

5. Verify that the -external service is available.

   $ oc get services | grep external
   
   NAME                         TYPE            CLUSTER-IP    EXTERNAL-IP   PORT(S)
   example-infinispan-external  LoadBalancer    192.0.2.24    hostname.com  11222/TCP

Procedure

1. Include spec.expose in your Infinispan CR.
2. Specify NodePort as the service type with the spec.expose.type field.

3. Configure the port where Data Grid is exposed with the spec.expose.nodePort field.

   spec:
     expose:
       type: NodePort
       nodePort: 30000

4. Apply the changes.

5. Verify that the -external service is available.

   $ oc get services | grep external
   
   NAME                         TYPE            CLUSTER-IP       EXTERNAL-IP   PORT(S)
   example-infinispan-external  NodePort        192.0.2.24       <none>        11222:30000/TCP

Procedure

1. Include spec.expose in your Infinispan CR.
2. Specify Route as the service type with the spec.expose.type field.

3. Optionally add a hostname with the spec.expose.host field.

   spec:
     expose:
       type: Route
       host: www.example.org

4. Apply the changes.

5. Verify that the route is available.

   $ oc get routes
   
   NAME                 CLASS    HOSTS   ADDRESS   PORTS   AGE
   example-infinispan   <none>   *                 443     73s

1. In the OpenShift Web Console, select the </> Developer perspective and then select Monitoring.
2. Open the Dashboard tab for the namespace where your Data Grid cluster runs.

3. Open the Metrics tab and confirm that you can query Data Grid metrics such as:

   vendor_cache_manager_default_cluster_size

Procedure

1. Create a ServiceAccount that lets Grafana read Data Grid metrics from Prometheus.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: infinispan-monitoring

   1. Apply the ServiceAccount.

      $ oc apply -f service-account.yaml

   2. Grant cluster-monitoring-view permissions to the ServiceAccount.

      $ oc adm policy add-cluster-role-to-user cluster-monitoring-view -z infinispan-monitoring

2. Create a Grafana data source.

   1. Retrieve the token for the ServiceAccount.

      $ oc serviceaccounts get-token infinispan-monitoring
      
      eyJhbGciOiJSUzI1NiIsImtpZCI6Imc4O...

   2. Define a GrafanaDataSource that includes the token in the spec.datasources.secureJsonData.httpHeaderValue1 field, as in the following example:

      apiVersion: integreatly.org/v1alpha1
      kind: GrafanaDataSource
      metadata:
        name: grafanadatasource
      spec:
        name: datasource.yaml
        datasources:
          - access: proxy
            editable: true
            isDefault: true
            jsonData:
              httpHeaderName1: Authorization
              timeInterval: 5s
              tlsSkipVerify: true
            name: Prometheus
            secureJsonData:
              httpHeaderValue1: >-
                Bearer
                eyJhbGciOiJSUzI1NiIsImtpZCI6Imc4O...
            type: prometheus
            url: 'https://thanos-querier.openshift-monitoring.svc.cluster.local:9091'

3. Apply the GrafanaDataSource.

   $ oc apply -f grafana-datasource.yaml

Procedure

1. Create a ConfigMap named infinispan-operator-config in the Data Grid Operator namespace.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: infinispan-operator-config
   data:
     grafana.dashboard.namespace: example-infinispan
     grafana.dashboard.name: infinispan
     grafana.dashboard.monitoring.key: middleware

2. Specify the namespace of your Data Grid cluster with the data.grafana.dashboard.namespace property.

   Note

   Deleting the value for this property removes the dashboard. Changing the value moves the dashboard to that namespace.

3. Specify a name for the dashboard with the data.grafana.dashboard.name property.
4. If necessary, specify a monitoring key with the data.grafana.dashboard.monitoring.key property.

5. Create infinispan-operator-config or update the configuration.

   $ oc apply -f infinispan-operator-config.yaml

6. Open the Grafana UI, which is available at:

   $ oc get routes grafana-route -o jsonpath=https://"{.spec.host}"

Procedure

1. Create an Infinispan CR for each Data Grid cluster.
2. Specify the name of the local site with spec.service.sites.local.name.
3. Set the value of the spec.service.sites.local.expose.type field to either NodePort or LoadBalancer.

4. Optionally configure ports with the following fields:

   • spec.service.sites.local.expose.nodePort if you use NodePort.
   • spec.service.sites.local.expose.port if you use LoadBalancer.

5. Provide the name and static URL for each Data Grid cluster that acts as a backup location with spec.service.sites.locations, for example:

   • LON

     apiVersion: infinispan.org/v1
     kind: Infinispan
     metadata:
       name: example-infinispan
     spec:
       replicas: 3
       service:
         type: DataGrid
         sites:
           local:
             name: LON
             expose:
               type: LoadBalancer
               port: 65535
           locations:
             - name: NYC
               url: infinispan+xsite://infinispan-nyc.myhost.com:7900
       logging:
         categories:
           org.jgroups.protocols.TCP: error
           org.jgroups.protocols.relay.RELAY2: error

   • NYC

     apiVersion: infinispan.org/v1
     kind: Infinispan
     metadata:
       name: example-infinispan
     spec:
       replicas: 2
       service:
         type: DataGrid
         sites:
           local:
             name: NYC
             expose:
               type: LoadBalancer
               port: 65535
           locations:
             - name: LON
               url: infinispan+xsite://infinispan-lon.myhost.com
       logging:
         categories:
           org.jgroups.protocols.TCP: error
           org.jgroups.protocols.relay.RELAY2: error

     Important

     Be sure to adjust logging categories in your Infinispan CR to decrease log levels for JGroups TCP and RELAY2 protocols. This prevents a large number of log files from uses container storage.

     spec:
       logging:
         categories:
           org.jgroups.protocols.TCP: error
           org.jgroups.protocols.relay.RELAY2: error

6. Configure your Infinispan CRs with any other Data Grid service resources and then apply the changes.

7. Verify that Data Grid clusters form a cross-site view.

   1. Retrieve the Infinispan CR.

      $ oc get infinispan -o yaml

   2. Check for the type: CrossSiteViewFormed condition.

Procedure

1. Create an Infinispan CR for each Data Grid cluster.
2. Specify the name of the local site with spec.service.sites.local.name.
3. Set ClusterIP as the value of the spec.service.sites.local.expose.type field.
4. Provide the name of the Data Grid cluster that acts as a backup location with spec.service.sites.locations.clusterName.

5. If both Data Grid clusters have the same name, specify the namespace of the backup location with spec.service.sites.locations.namespace.

   apiVersion: infinispan.org/v1
   kind: Infinispan
   metadata:
     name: example-clustera
   spec:
     replicas: 1
     expose:
       type: LoadBalancer
     service:
       type: DataGrid
       sites:
         local:
           name: SiteA
           expose:
             type: ClusterIP
         locations:
           - name: SiteB
             clusterName: example-clusterb
             namespace: cluster-namespace

6. Configure your Infinispan CRs with any other Data Grid service resources and then apply the changes.

7. Verify that Data Grid clusters form a cross-site view.

   1. Retrieve the Infinispan CR.

      $ oc get infinispan -o yaml

   2. Check for the type: CrossSiteViewFormed condition.

Procedure

1. Add the spec.affinity block to your Infinispan CR.
2. Configure anti-affinity strategies as necessary.
3. Apply your Infinispan CR.

Procedure

1. Create a Cache CR that contains an XML cache configuration.

   1. Specify a name for the Cache CR with the metadata.name field.
   2. Specify the target Data Grid cluster with the spec.clusterName field.

   3. Name your cache with the spec.name field.

      Note

      The name attribute in the XML configuration is ignored. Only the spec.name field applies to the resulting cache.

   4. Add an XML cache configuration with the spec.template field.

      apiVersion: infinispan.org/v2alpha1
      kind: Cache
      metadata:
        name: mycachedefinition
      spec:
        clusterName: example-infinispan
        name: mycache
        template: <distributed-cache name="mycache" mode="SYNC"><persistence><file-store/></persistence></distributed-cache>

2. Apply the Cache CR, for example:

   $ oc apply -f mycache.yaml
   cache.infinispan.org/mycachedefinition created

Procedure

1. Create a Cache CR that specifies the name of a template to use.

   1. Specify a name for the Cache CR with the metadata.name field.
   2. Specify the target Data Grid cluster with the spec.clusterName field.
   3. Name your cache with the spec.name field.

   4. Specify a cache template with the spec.template field.

      The following example creates a cache named "mycache" from the org.infinispan.DIST_SYNC cache template:

      apiVersion: infinispan.org/v2alpha1
      kind: Cache
      metadata:
        name: mycachedefinition
      spec:
        clusterName: example-infinispan
        name: mycache
        templateName: org.infinispan.DIST_SYNC

2. Apply the Cache CR, for example:

   $ oc apply -f mycache.yaml
   cache.infinispan.org/mycachedefinition created

Procedure

1. Create cache configurations that name remote sites as backup locations.

   Data Grid replicates data based on cache names. For this reason, site names in your cache configurations must match site names, spec.service.sites.local.name, in your Infinispan CRs.

2. Configure backup locations to go offline automatically with the take-offline element.

   1. Set the amount of time, in milliseconds, before backup locations go offline with the min-wait attribute.
3. Define any other valid cache configuration.

4. Add backup locations to the named cache on all sites in the global cluster.

   For example, if you add LON as a backup for NYC you should add NYC as a backup for LON.

Procedure

1. Create a Batch CR.

   1. Specify the name of the Data Grid cluster where you want the batch operations to run as the value of the spec.cluster field.

   2. Add each CLI command to run on a line in the spec.config field.

      apiVersion: infinispan.org/v2alpha1
      kind: Batch
      metadata:
        name: mybatch
      spec:
        cluster: example-infinispan
        config: |
          create cache --template=org.infinispan.DIST_SYNC mycache
          put --cache=mycache hello world
          put --cache=mycache hola mundo

2. Apply your Batch CR.

   $ oc apply -f mybatch.yaml

3. Check the status.Phase field in the Batch CR to verify the operations completed successfully.

Procedure

1. Create a batch file that contains all commands you want to run.

   For example, the following batch file creates a cache named "mycache" and adds two entries to it:

   create cache mycache --file=/etc/batch/mycache.xml
   put --cache=mycache hello world
   put --cache=mycache hola mundo

   Important

   The ConfigMap is mounted in Data Grid pods at /etc/batch. You must prepend all --file= directives in your batch operations with that path.

2. Ensure all configuration artifacts that your batch operations require are in the same directory as the batch file.

   $ ls /tmp/mybatch
   
   batch
   mycache.xml

3. Create a ConfigMap from the directory.

   $ oc create configmap mybatch-config-map --from-file=/tmp/mybatch

Procedure

1. Create a Batch CR that specifies the name of a Data Grid cluster as the value of the spec.cluster field.

2. Set the name of the ConfigMap that contains your batch file and configuration artifacts with the spec.configMap field.

   $ cat > mybatch.yaml<<EOF
   apiVersion: infinispan.org/v2alpha1
   kind: Batch
   metadata:
     name: mybatch
   spec:
     cluster: example-infinispan
     configMap: mybatch-config-map
   EOF

3. Apply your Batch CR.

   $ oc apply -f mybatch.yaml

4. Check the status.Phase field in the Batch CR to verify the operations completed successfully.

Procedure

1. Name the Backup CR with the metadata.name field.
2. Specify the Data Grid cluster to backup with the spec.cluster field.

3. Configure the persistent volume claim (PVC) that adds the backup archive to the persistent volume (PV) with the spec.volume.storage and spec.volume.storage.storageClassName fields.

   apiVersion: infinispan.org/v2alpha1
   kind: Backup
   metadata:
     name: my-backup
   spec:
     cluster: source-cluster
     volume:
       storage: 1Gi
       storageClassName: my-storage-class

4. Optionally include spec.resources fields to specify which Data Grid resources you want to back up.

   If you do not include any spec.resources fields, the Backup CR creates an archive that contains all Data Grid resources. If you do specify spec.resources fields, the Backup CR creates an archive that contains those resources only.

   spec:
     ...
     resources:
       templates:
         - distributed-sync-prod
         - distributed-sync-dev
       caches:
         - cache-one
         - cache-two
       counters:
         - counter-name
       protoSchemas:
         - authors.proto
         - books.proto
       tasks:
         - wordStream.js

   You can also use the * wildcard character as in the following example:

   spec:
     ...
     resources:
       caches:
         - "*"
       protoSchemas:
         - "*"

5. Apply your Backup CR.

   $ oc apply -f my-backup.yaml

Verification

1. Check that the status.phase field has a status of Succeeded in the Backup CR and that Data Grid logs have the following message:

   ISPN005044: Backup file created 'my-backup.zip'

2. Run the following command to check that the backup is successfully created:

   $ oc describe Backup my-backup

Procedure

1. Name the Restore CR with the metadata.name field.
2. Specify a Backup CR to use with the spec.backup field.

3. Specify the Data Grid cluster to restore with the spec.cluster field.

   apiVersion: infinispan.org/v2alpha1
   kind: Restore
   metadata:
     name: my-restore
   spec:
     backup: my-backup
     cluster: target-cluster

4. Optionally add the spec.resources field to restore specific resources only.

   spec:
     ...
     resources:
       templates:
         - distributed-sync-prod
         - distributed-sync-dev
       caches:
         - cache-one
         - cache-two
       counters:
         - counter-name
       protoSchemas:
         - authors.proto
         - books.proto
       tasks:
         - wordStream.js

5. Apply your Restore CR.

   $ oc apply -f my-restore.yaml

Procedure

1. Change to the namespace for your Data Grid cluster.

   $ oc project rhdg-namespace

2. Create a PVC for your custom code artifacts, for example:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: datagrid-libs
   spec:
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: 100Mi

3. Apply your PVC.

   $ oc apply -f datagrid-libs.yaml

4. Create a pod that mounts the PVC, for example:

   apiVersion: v1
   kind: Pod
   metadata:
     name: datagrid-libs-pod
   spec:
     securityContext:
       fsGroup: 2000
     volumes:
       - name: lib-pv-storage
         persistentVolumeClaim:
           claimName: datagrid-libs
     containers:
       - name: lib-pv-container
         image: registry.redhat.io/datagrid/datagrid-8-rhel8:8.2
         volumeMounts:
           - mountPath: /tmp/libs
             name: lib-pv-storage

5. Add the pod to the Data Grid namespace and wait for it to be ready.

   $ oc apply -f datagrid-libs-pod.yaml
   $ oc wait --for=condition=ready --timeout=2m pod/datagrid-libs-pod

6. Copy your code artifacts to the pod so that they are loaded into the PVC.

   For example to copy code artifacts from a local libs directory, do the following:

   $ oc cp --no-preserve=true libs datagrid-libs-pod:/tmp/

7. Delete the pod.

   $ oc delete pod datagrid-libs-pod

   Specify the persistent volume with spec.dependencies.volumeClaimName in your Infinispan CR and then apply the changes.

   apiVersion: infinispan.org/v1
   kind: Infinispan
   metadata:
     name: example-infinispan
   spec:
     replicas: 2
     dependencies:
       volumeClaimName: datagrid-libs
     service:
       type: DataGrid

Procedure

1. Add the spec.dependencies.artifacts field to your Infinispan CR.

   1. Specify the location of the file to download via HTTP or FTP as the value of the spec.dependencies.artifacts.url field.

   2. Optionally specify a checksum to verify the integrity of the download with the spec.dependencies.artifacts.hash field.

      The hash field requires a value is in the format of <algorithm>:<checksum> where <algorithm> is sha1|sha224|sha256|sha384|sha512|md5.

   3. Set the file type, if necessary, with the spec.dependencies.artifacts.type field.

      You should explicitly set the file type if it is not included in the URL or if the file type is actually different to the extension in the URL.

      Note

      If you set type: file, Data Grid Operator downloads the file as-is without extracting it to the filesystem.

      apiVersion: infinispan.org/v1
      kind: Infinispan
      metadata:
        name: example-infinispan
      spec:
        replicas: 2
        dependencies:
          artifacts:
            - url: http://example.com:8080/path
              hash: sha256:596408848b56b5a23096baa110cd8b633c9a9aef2edd6b38943ade5b4edcd686
              type: zip
        service:
          type: DataGrid

2. Apply the changes.

Procedure

1. Add spec.cloudEvents to your Infinispan CR.

   1. Configure the number of acknowledgements with the spec.cloudEvents.acks field. Values are "0", "1", or "all".
   2. List Kafka servers to which Data Grid sends events with the spec.cloudEvents.bootstrapServers field.

   3. Specify the Kafka topic for Data Grid events with the spec.cloudEvents.cacheEntriesTopic field.

      spec:
        cloudEvents:
          acks: "1"
          bootstrapServers: my-cluster-kafka-bootstrap_1.<namespace_1>.svc:9092,my-cluster-kafka-bootstrap_2.<namespace_2>.svc:9092
          cacheEntriesTopic: target-topic

2. Apply your changes.

Procedure

1. Create a CLI connection to your Data Grid cluster.

   Using the server distribution

   $ bin/cli.sh -c https://$SERVICE_HOSTNAME:$PORT --trustall

   Using the native CLI

   $ ./redhat-datagrid-cli -c https://$SERVICE_HOSTNAME:$PORT --trustall

   Replace $SERVICE_HOSTNAME:$PORT with the hostname and port where Data Grid is available on the network.

2. Enter your Data Grid credentials when prompted.

3. Perform CLI operations as required, for example:

   1. List caches configured on the cluster with the ls command.

      [//containers/default]> ls caches
      mycache

   2. View cache configuration with the describe command.

      [//containers/default]> describe caches/mycache