Skip to main content
Domino Volumes for NetApp ONTAP provides a centralized data storage solution that integrates Domino with external NetApp-backed infrastructure. It enables cross-project data sharing, improves I/O performance, eliminates redundancy, and supports snapshot-based recovery. Volumes reside within ONTAP filesystems, which bind a Domino dataplane and storage class to a named storage container. This architecture supports multi-account scaling, provides precise visibility into storage allocation, and enables retention-aware deletion through cold storage offloading. This guide provides step-by-step instructions for manually configuring NetApp Volumes in a Domino deployment, intended for administrators managing infrastructure in AWS environments.

​
Prerequisites

Before you can begin working with NetApp Volumes, you’ll need to verify that you have these prerequisites in place:
ComponentDescription
DominoHave a Domino deployed and configured.
ONTAP filesystemHave a supported ONTAP filesystem. This is where the volumes will be made and how they will interact with your underlying infrastructure.
TridentInstalled and working with your file system.
CommunicationVerified that Domino and ONTAP can talk to each other.
Storage ConfigurationRoot system file name: This is the base of the filesystem where all other volumes are mounted.
Feature FlagVerify that the feature flag EnableDominoNetAppVolumes is set to true.

​
Kubernetes configuration for Domino

There are a couple of steps you’ll need to take to configure Kubernetes for Domino.
  • Role and RoleBinding: A Kubernetes Role and RoleBinding are required to enable the microservice to authenticate and communicate with Trident.
  • Network policy: You’ll also need a network policy to allow the right Kubernetes resources to communicate with Trident.

​
Create Role and RoleBinding

You can use these examples as-is to create and apply your Role and RoleBinding:

​
Create Role

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: data-plane-agent
  namespace: trident
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
Apply the Role: 
vim <my_role>.yaml  # copy/paste the contents above
kubectl apply -f <my_role>.yaml

​
Create RoleBinding

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: data-plane-agent
  namespace: trident
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: data-plane-agent
subjects:
  - kind: ServiceAccount
    name: data-plane-agent
    namespace: domino-compute
Apply the RoleBinding: 
vim <my_role_binding>.yaml  # copy/paste the contents above
kubectl apply -f <my_role_binding>.yaml

​
Create a Network Policy

Use this example as a template for your NetworkPolicy resource: 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: trident-operator
  namespace: trident
spec:
  podSelector:
    matchLabels:
      app: controller.csi.trident.netapp.io
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from: []
      ports:
        - protocol: TCP
          port: 8443
        - protocol: TCP
          port: 8001
  egress:
    - to: []
Apply the Policy: 
vim <my_network_policy>.yaml  # copy/paste the contents above
kubectl apply -f <my_network_policy>.yaml

​
Create a Root PVC

When you created a filesystem in Amazon FSx or NetApp Cloud ONTAP, it included a special root volume at the path /. This is the base of the filesystem where all other volumes are mounted. To make it usable in Domino, you’ll need to create a Kubernetes PersistentVolumeClaim (PVC) that maps to this root volume. The example below shows how to define that PVC using an import: 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fsx-imported-volume                                                     # Arbitrary name
  namespace: domino-compute                                                     # Should always be the compute namespace
  labels:
    dominodatalab.com/netapp-storage: "true"                                    # IMPORTANT. This is needed so the Root PVC can be found during Filesystem creation (in the next step)
  annotations:
    trident.netapp.io/importBackendUUID: "c9c51153-a02d-4f67-b3ca-6e11c8e80ee2" # This can be found by inspecting the tridentbackendconfig custom resource in the cluster, under the status.backendInfo.backendUUID field
    trident.netapp.io/importOriginalName: demo_root                             # Name of the root volume in your Filesystem. Can be found in AWS FSx UI (The name is usually <deployment_id>_svm_root)
    trident.netapp.io/notManaged: "false"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 953Mi
  storageClassName: democlass                                                   # Use the storage class of the trident storage class in the cluster
  volumeMode: Filesystem
Apply Root PVC: 
vim <root_pvc>.yaml <paste template and change values> kubectl apply -f <root_pvc>.yaml
Verify status: 
kubectl get pvc <root_pvc> -n domino-compute
Make sure the returned message indicates STATUS - Success. Your Domino deployment is now fully configured to use NetApp Volumes for scalable, managed storage.

​
Next Steps