We have recently made a push to publish our software to the snap store, however, we identified that we will need some snaps to have classic confinement. The snaps are:
license-manager-agent (couldn’t put the link because new users can put only 2 links :/)
The technical detail that we identified is the fact that these agents interact with the slurm binaries, more specifically scontrol, sbatch, sacctmgr and squeue. The common path where these binaries are located at is /usr/bin, however, it’s up for the HPC admin of a cluster to determine exactly where they are, so we need to allow end users to customize the binaries’ paths in the agents. For this reason, we needed to make the snaps to have classic confinement.
Hey @matheushent, according to Process for reviewing classic confinement snaps , Classic requests should fall under at least one of the supported categories. Could you please clarify if these snaps fit within any of the supported categories? Thanks!
HPC or orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent (ie, the software simply orchestrates running workloads on systems and doesn’t manage the systems themselves).
Essentially, the snaps install agents whose purpose are to assist end users to manage licenses and submit workloads.
Hey @jslarraz. Despite being possible to pack the slurm binaries in the snap (check out slurm-snap in which @nuccitheboss has contributed), the agents are supposed to work with existing slurm clusters, which means the binaries and configuration files will be already existing for most use cases.
Consider the scenario where Slurm is already being run in the system. This means the *.conf files are all in place and the slurm daemons (slurmctld, slurmdbd, slurmd and possibly slurmrestd) are already running. If the agents stage the slurm binaries, this means the agents will not be able to communicate with the existing cluster, therefore there’s no value in installing them.
