[Feature]: Volume lifecycle management

[peterschmidt85]

1.1. [Long-term] Registering an existing network volume

They want to be able to register an existing volume (just like we already support for AWS).

Example for AWS:

type: volume
name: my-volume

backend: aws
region: eu-central-1

# The ID of the volume in AWS
volume_id: vol1235

Additionally, they want to be able to specify a subpath (which will be mounted, i.e., as a prefix):

type: volume
name: my-volume

backend: aws
region: eu-central-1

# The ID of the volume in AWS
volume_id: vol1235
path: <subpath inside the volume>
cleanup: true

When mounting this volume (by name — same as with regular network volumes), only this specified subpath (path) should be mounted.

When deleting such a volume, they want an option to automatically clean it up (we could implement this by running a “system” task, for example), if cleanup is set to true.

This can be implemented once we support network volumes on Nebius. Until then, as a temporary solution, we could support registering an instance volume (see 1.2 below).

1.2. [Mid-term] Registering an existing instance volume

Since network volumes on Nebius are not yet supported, users would like to keep using SSH fleets, but still have the option to register volumes.

type: volume
name: my-volume

fleet: my-fleet
instance_path: <subpath inside the fleet instance>
cleanup: true

This configuration implies that instance_path on the instances of the specified fleet points to a folder where shareable network storage is mounted.

When deleting, same as with a network volume (see 1.1 above), automatic data cleanup could be implemented via a system task if cleanup is set to true.

1.3. [Short-term] Workaround

Until 1.2 is implemented, users need to manually mount separate volumes to the SSH fleet instances and refer to them using instance volumes.