volumes:
section of the platform configuration YAML file. In AE 5.4 and earlier, this was limited strictly to NFS volumes.
With AE 5.5 and the Bring your own Kubernetes option, this capability has been extended to support standard Kubernetes Persistent Volumes (PVs) and Persistent Volume Claims (PVCs). This addition allows sessions, deployments, and pods to access a much wider variety of shared volumes. The specific set choices available to you will depend on the specific Kubernetes implementation and host. See this section of the Kubernetes documentation for a list of volume types—but again, check the documentation for your specific Kubernetes provider for the subset of those choices available to you.
Before you begin:
Adding a new file share requires editing the Anaconda Enterprise ConfigMap and restarting the workspace and deploy pods. For that reason, Anaconda recommends scheduling a maintenance window for this task and backing up the current version of anaconda-enterprise-anaconda-platform.yml
before making changes to it.
volumes:
section of the ConfigMap, as seen in the following example:
/
, then it is assumed to be relative to the /data
subdirectory. So, for instance, the second mount path above will be /data/relative/path2
.
subPath
(optional): the subfolder of the shared filesystem to mount. Any leading slashes are ignored, and the path is assumed relative to the root of the exported mount. This is a somewhat advanced configuration; see SubPaths and Template Expansion section below for an advanced use case that can take advantage of this option.
readOnly
(optional): if true
, the file share will be mounted as read-only; that is, sessions, deployments, and jobs will not be able to write to the volume. If false
, or omitted entirely, the file share will be mounted read-write.
readOnly
flag can be provided in two different locations: either within the nfs
specification or outside of it. The volume will be mounted read-only if either value is true
.groupID
(optional): a Unix GID which has read and/or write access to the volume. See the section Ensuring Access below for more information.
Finally, the volume specification itself is given by one of the two entries: pvc
or nfs
.
pvc
: the name of the Kubernetes Persistent Volume Claim. This PVC must meet the following criteria:
readOnly
is false
, it must have a ReadWriteMany
access policy. If readOnly
is true
, it must be either ReadWriteMany
or ReadOnlyMany
.nfs
: this is an NFS import specification, and its syntax has not changed from AE 5.4—and remains the only option for multi-node, Gravity-based clusters.
server
: the FQDN or IP address of the NFS server.path
: the exported path from the NFS server.readOnly
: see above.pv.beta.kubernetes.io/gid
Persistent Volume annotation. (This must be added to the PV, not to the PVC.) Many persistent volume providers do this automatically—if so, AE 5.5 will pick this up automatically as well, and no further configuration is needed.groupID
option above.0,1001,1234
. Files accessible by any of these three GIDs will be accessible.
To access volumes with more complex Unix access permissions, including individual user permissions, the Authenticated NFS integration pattern will likely be necessary. See the dedicated documentation for that pattern for details.
anaconda-enterprise-anaconda-platform.yml
configuration file.
kubectl get pods
. Examine the workspace and deploy pods. You may still see the old versions of the pods shutting down, which is expected. The new pods should be running as expected. If for some reason there are errors, it is likely because your ConfigMap is improperly formatted. Double check your editing and repeat steps 5 through 7 above to correct the issue.
volume
section.subPath
option can be used to mount just a subdirectory of a shared volume at multiple mount points in the session. Anything above that subdirectory would not be visible within the container. For example, consider a shared volume with the following fileset:
pv1
, and consider the following mount configuration:
/data
path, the container would see the following tree:
testA
is not accessible at all, and the user1
and user2
are not even at the same “depth” of the directory tree anymore. As a result, sub path mounting offers a simple form of access control, allowing only portions of a shared volume to be made available to sessions, deployments, and jobs.
The usefulness of this subpath functionality has been enhanced with simple templating functionality. Specifically, the subPath
value can include one or more of the following strings (braces included), and AE5 will dynamically substitute a relevant value in its place:
{user}
: the username of the person running the session, deployment, or job{owner}
: the username of the owner of the project associated with the session, deployment, or job. These will differ in a collaboration scenario: if userA
created a project and shared it with userB
, who is now running a session, {user}
would be userB
and {owner}
would be userA
.{id}
: the 32-character uuid of the session, deployment, or job.{project}
: the 32-character uuid of the project itself. This will be the same across all sessions, deployments, and jobs associated with that project.userA
, and a session being run by userB
, the three subpaths might be