The csi-netapp module: configuration

How much of a volume is reserved for the superuser?

Nothing, by default: the module tells Trident to format with -m0, so the whole volume is available to the workload.

Where the classic 5% ext4 reserve is wanted — for example to keep a filesystem writable for a privileged process after a workload has filled it — annotate the NetappStorageConnection with the percentage to reserve:

d8 k annotate netappstorageconnection <name> storage.deckhouse.io/ext4-reserved-percent=5

Note the resource: unlike the other storage modules, the percentage is set per connection, not per StorageClass. Trident keeps the mkfs options on the backend, so the value applies to every StorageClass served by that connection.

The value is a whole number of percent between 0 and 50; an invalid one leaves the NetappStorageConnection with Ready=False and the reason in its status, instead of breaking volume creation later.

The reserve applies only to volumes created after the annotation was set — filesystems that already exist keep the reserve they were created with.

Where do open-iscsi and multipath-tools on a node come from?

From the module itself. The NodeGroupConfiguration never asks the node’s package manager for them, so a node in a closed environment with no route to the distribution’s repositories is set up the same way as any other, and no bashible run waits on those repositories.

On every node it serves — those carrying storage.deckhouse.io/csi-netapp-node — bashible pulls the module’s package image iscsi-tools from the module’s registry, unpacks it and runs its install script. The stack is two pairs — iscsiadm with iscsid, and multipath with multipathd — and the script decides for each pair separately:

• a pair the host already has of its own stays the host’s, and the module only enables and configures the distribution’s unit for its daemon;
• a pair the host lacks lands under /var/lib/deckhouse/sds/csi-netapp, every binary is started through its own dynamic loader with its own library path, and a unit of the module’s comes up for its daemon.

A client and its daemon always come from the same source, because iscsiadm of one version does not speak to iscsid of another. The two pairs do not talk to each other, so a node may well run the host’s iscsid next to the module’s multipathd.

Everything else the NodeGroupConfiguration does runs the same whichever pair came from where: the find_multipaths no override, the NetApp ONTAP device block, the kernel modules, and the storage.deckhouse.io/csi-netapp-node-ready label the CSI node waits for.

Two things the install script arranges for a pair it lands that are worth knowing about, because both are invisible until something does not mount.

Trident reaches iscsiadm, multipath and multipathd on the host by name, through nsenter, so each name is resolved against the container’s PATH inside the host’s mount namespace. The script leaves a wrapper in /usr/local/sbin for each of these tools that comes from the module, and each wrapper prefers a distribution binary the moment one appears.

And multipathd from the package reads its configuration under the prefix it was built with, not under /etc. The script links multipath.conf and multipath from that prefix onto the node’s own. Without that link Trident’s own pre-flight checks see find_multipaths: yes and refuse to stage a volume at all.

To tell which pair a node took from where, look at what is running on it:

# the distribution's daemons
systemctl is-active iscsid multipathd
# the module's daemons and binaries
systemctl is-active d8-csi-netapp-iscsid.service d8-csi-netapp-multipathd.service
ls /var/lib/deckhouse/sds/csi-netapp/bin
multipathd show config | grep find_multipaths

The module’s stack changes little on the host itself. Its libraries are never merged into the host’s /lib64 or /usr/lib. The only files it puts outside its own directory are the wrappers and links described above and the multipath path checkers in /usr/lib/multipath, where multipathd looks for them; each of them only where the host has no file of its own, and each taken back once the host has the pair it belongs to. And it does not touch /etc/iscsi/initiatorname.iscsi when the node already has one: the IQN is the node’s identity on the array, registered there in a host object, and a node that comes back under a different name is a node the array has never heard of.

Requirements

To the Deckhouse Platform version: 1.72 and above.

Parameters

Schema version: 1

• settings

  object
  • settings.logLevel

    string

    The verbosity level of the module’s log output.

    Default: INFO

    Allowed values: ERROR, WARN, INFO, DEBUG, TRACE

  • settings.nodeSelector

    object

    Specifies where shares can be mounted. Works the same way as the spec.nodeSelector parameter in Kubernetes Pods. If this parameter is omitted, NetApp shares can be mounted on any node in the cluster running the Linux OS.

    Default: { "kubernetes.io/os": "linux" }

  • settings.storageClassLabelIgnoredPrefixes

    array of strings

    List of label-key prefixes that MUST NOT be propagated from a NetappStorageClass to the managed Kubernetes StorageClass.

    The controller treats this list as a complement to a built-in (system) list and drops any NetappStorageClass label whose key starts with any prefix from either list.

    The defaults cover labels typically added by GitOps tooling (Argo CD, Flux, Rancher Fleet) so that their reconcilers do not fight the storage controller over labels on the managed StorageClass.

    Default: [ "argocd.argoproj.io/", "kustomize.toolkit.fluxcd.io/", "helm.toolkit.fluxcd.io/", "fleet.cattle.op/" ]