Customizing resource on DG Operator pod itself in OCP 4

Solution Verified - Updated

Environment

  • Red hat OpenShift Container Platform (OCP)
    • 4.x
  • Red Hat Data Grid (RHDG)
    • 8.x

Issue

  • How to customize resource on Operator pod itself?
  • How to increase DataGrid pod resources?
  • Increasing DG pod resources

Resolution

For customizing the Operator itself (the pod operator) the values must be set on the respective Data Grid's Subscription, which is listened to by the OLM - in case of issues, like prevention of leader election timing out:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata: 
  name: datagrid
spec: 
  channel: 8.3.x
  installPlanApproval: Manual
  name: datagrid
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: datagrid-operator.v8.3.6
  config: 
    resources: 
      requests: 
        memory: "64Mi"
        cpu: "250m"
      limits: 
        memory: "128Mi"
        cpu: "500m"

Changing Java max ratio percentage

Currently the user can only use Xmx or set JAVA_MAX_MEM_RATIO env on the Subscription:

kind: Subscription
spec:
  ...
  config:
    env:
    - name: ADDITIONAL_VARS
      value: "[\"JAVA_MAX_MEM_RATIO\"]"
    - name: JAVA_MAX_MEM_RATIO
      value: "25"

Root Cause

Increasing the DG Operator resources can be useful when many Infinispan Custom Resources are being handled by the Operator, e.g. 100/200+ Caches/Infinispan CRs. So then the leader might timeout as above, and editing the Subscription can be used to increase its resources directly without editing/changing the deployment, which will be overwritten by the OLM.

For customizations on the Infinispan Custom resource, see the solution Using custom configuration in DG 8 via Operator.

Although DataGrid does not allow (and doesn't support), a few operators allow direct deployment, meaning creating directly the operator pods (deployment+csv+crds) and not via subscription YAML, see details below.

Depending on the Operator, you have the container resources being defined in the CSV (cryostat, argo) others don't have it at all (DG, MTA). Some do not have the section CSV.install.spec.deployments, which define their respective operator container managers.

Data Grid does not have CSV.install.spec.deployments, so the changes above will go straight to the DG deployment pod straight, not the CSV. Example: RHACS and GitOps, and Argo.

However, for those ones that do have, may allow you to change at the level:

DetailsExample OperatorDetails
It does not have CSV.install.spec.deploymentsDataGridChange on Subscription or the deployment
It does have CSV.install.spec.deploymentsRHACS and GitOps, and ArgoChange on Subscription, CSV or the deployment
  • If the Subscription does not push down the  CSV for that, and technically the CSV has the ownership of the deployment, so user changes will not get overwritten.

  • Whereas if the user set on the deployment, the new CSV would come and overwrite the deployment perhaps (given it has ownership of that)

Diagnostic Steps

  1. See the subscription via: $ oc get sub. And CSV via $ oc get csv.
  2. See the deployment via: $ oc get deployment.
Product(s)
Components
Category

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.