Control storage class of container / container_request output
New field on container called
New field on container_request called
When accepting a container request and creating a new container, the new container should take the storage classes from the request. Crunch-run will ensure that container outputs are sent to that storage class.
The output collection of the file will be assigned the storage classes from
- crunch-run will respect the value of
output_storage_classeson the container record when writing the output collection.
When we create the container request output collection (copied from the container output) the new collection is assigned the storage classes from the container_request
#8 Updated by Peter Amstutz 4 months ago
17395-container-output-storage-class @ 4dfa520bd6eb1c594c83f85431d6a39e340fa9cb
- Migration to add output_storage_classes to container and container_request
- Add OutputStorageClasses to Container and ContainerRequest in Go SDK
- Use Container.OutputStorageClasses to set the storage classes used by the "dispatcher" and "container" keep clients used in crunch-run.
- Add tests & update API documentation.
#10 Updated by Lucas Di Pentima 4 months ago
Some comments below:
- It seems that the migration file is missing.
- There's a sentence on the docs: "This feature does not provide a hard guarantee on where data will be stored. Data may be written to default storage and moved to the desired storage class later. If controlling data locality is a hard requirement (such as legal restrictions on the location of data) we recommend setting up multiple Arvados clusters." at the end of https://doc.arvados.org/v2.2/admin/storage-classes.html -- not sure if this story is the right one but I think we'll need to fix it as soon it won't be completely correct.
- Somewhat related: Should keepproxy use the newly created
services/keepproxy/keepproxy.goLine 477? Also, some tests could use it.
- Other than that, it LGTM.