Uses configuration file to specify applications, schedulers and filesystems.
By default uses first scheduler and first filesystem to upload input, submit, state fetch, download output.
To test the multi scheduler support you have to create a config.yaml file by copying config-example.yaml. The example config file uses a in-memory scheduler on the local file system. To use the Slurm scheduler and sftp filesystem
you have to uncomment the slurmcontainer block and
start up a Slurm Docker container as described in the config file.
you should be able to submit a job that
Copies input files to container in /home/xenon/<job_id>, which you can verify with docker exec <container id> ls -l /home/xenon/<job_id>
Submit job to Slurm, which you can verify by running sacct to see the completed job.
After job completion will copy the output files back to where bartender serve is running, which you can verify with ls /tmp/jobs/*, it should have a stdout.txt file.
Uses configuration file to specify applications, schedulers and filesystems. By default uses first scheduler and first filesystem to upload input, submit, state fetch, download output.
To test the multi scheduler support you have to create a config.yaml file by copying config-example.yaml. The example config file uses a in-memory scheduler on the local file system. To use the Slurm scheduler and sftp filesystem
slurmcontainerblock and/home/xenon/<job_id>, which you can verify withdocker exec <container id> ls -l /home/xenon/<job_id>sacctto see the completed job.bartender serveis running, which you can verify withls /tmp/jobs/*, it should have a stdout.txt file.Also