Storage Segments

Not every cluster is uniform: some sites have groups of nodes that mount different shared filesystems, sit in different network zones, or otherwise cannot all reach the same storage. Segments let you describe that topology so the scheduler only places work on nodes that can actually reach the volumes the work needs.

A segment is a label shared between a storage provisioner and the node provisioner definitions whose nodes can mount that provisioner’s volumes:

• A storage provisioner with a segment restricts its volumes to nodes belonging to the same segment.
• A node provisioner definition with a segment marks the nodes it provisions as belonging to that segment.
• A storage provisioner without a segment remains globally accessible, so existing deployments are unaffected.

Segment names must be lowercase DNS labels: lowercase letters, digits, and hyphens, and they cannot start or end with a hyphen.

segment is a top-level field of the storage provisioner definition, alongside access and annotations (see Provisioner Definitions):

name: corp-dc-nfs
description: NFS reachable only from the corp datacenter nodes
driver:
  type: nfs
  target: "nfs.corp.example.com:/export/fuzzball"
access:
  - "research-lab"
segment: corp-dc

Node provisioner definitions in the central configuration accept the same key:

provisioners:
  definitions:
    - name: corp-dc-static
      type: static
      segment: corp-dc
      # ...

Nodes provisioned by this definition belong to the corp-dc segment and are the only nodes on which volumes from a corp-dc storage provisioner can be mounted.

Workflows that reference volumes from a segmented provisioner are only placed on nodes with a matching segment. Invalid combinations are caught early: a workflow referencing a volume from a non-existent segment, or combining volumes whose segments conflict, is rejected at submission with a clear error rather than failing at run time.

Image staging is segment-aware. When jobs in different segments reference the same container image, a separate image stage runs in each segment so the converted SIF image is cached on the shared filesystem that segment’s nodes actually mount. The distributed image pull lock is scoped per segment, so pulls in different segments proceed concurrently. Unsegmented workflows are unchanged.