Cluster volumes

[jennydaman]

Background

pfcon receives a ZIP file from CUBE and extracts its file contents to a subdirectory of a path given by the environment variable. It then sends to pman the name of this new subdirectory, and pman will concatenate its own STOREBASE with this subdirectory's name.

STOREBASE is an environment variable defined for both pfcon and pman and it must be the same for both. It is the path on the host filesystem which is the parent directory of mount points containing the data for jobs created by pman.

Issue

pfcon is not "cluster-aware" and reads/writes data files to its filesystem naively. Currently, pman's support for Kubernetes is hard-coded to use either HostPath or NFS. In other words, pfcon and pman interact with filesystems according to traditional, either single-node or NFS cluster architectures, and do not use more modern "cloud-native" (i.e. portable Kubernetes solutions) abstractions.

Specific to Kubernetes, a more flexible (and secure) solution would be to use storage classes, where: upon receiving a request to run a plugin instance from CUBE, two volumes are created using the scheduler's specific API (might be mkdir on an NFS in case of SLURM, or might be using a Docker volume plugin, or might be using Kubernetes storageClass) and these volumes are mounted by volume name (a scheduler technology specific abstraction) instead of by the paths where they exist on the host.

[Alero-Awani]

hello @jennydaman, I would like to work on this.

[jennydaman]

@Alero-Awani this issue is very large in scope. If you are interested in it, would you write a technical report proposing a detailed solution? Such a feat would count as a contribution for Outreachy. Once I review your proposal, we can debate it a bit before starting to work on it.

[Alero-Awani]

Hello, @jennydaman, still working on this, I am quite new to Kubernetes, so I have been some research on volumes and the Kubernetes API python-client. I will email the technical report as soon as I am done.

[jennydaman]

A much simpler solution which does not change pfcon is proposed here: FNNDSC/pman#227