The volume,in a browser tab
A multi-user file manager over the engine volume.Upload, unpack and stage a run without a client.
$ dxflow workflow create --identity files hub://filegator --start --link
The data moveswhere it already is
The directory it browses is the one Artifacts shows, and every workflow mounts.
It arrives in chunks, so a dropped connection continues instead of restarting.
Unpack a reference dataset in place, without it crossing the network twice.
Move one run's output into the directory the next workflow reads from.
An account,and how far it reaches
The administrator and the guest are reconciled from the environment on every start. Everyone else you add in the UI.
$ dxflow workflow start files --override env.app.PASSWORD=something-long
$ dxflow workflow start files --override env.app.ROOT_DIR=runs --override env.app.GUEST_PERMISSIONS=read|download --link
One port,and who you hand it to
An account per collaborator, each with a home directory and permissions of its own.
It works wherethe data already is
Unzipping a forty gigabyte archive should not mean pulling it to a laptop and pushing it back.
An archive is unpacked under the volume, so it never crosses the network twice. Size the storage for the contents, not the file.
Move a finished output into another workflow's input directory, and edit the parameter file in place on the way past.
A browser over the whole volume can delete as easily as it can stage. Set ROOT_DIR, and give collaborators an account with a home of its own.
Pulled once,then it stays
FileGator arrives as one image. This is what comes down the first time, and what the disk should have free for it.
What it wants,and what it needs
The definition asks for 2 cores and 2 GB. The image comes up on less than that, and a start given --fit trims the ask to whatever the machine actually has.
Machines that fit it
FileGator asks for 2 cores and 2 GB. Cheapest first.