Arvados

Lucas Di Pentima wrote:

UI Proposal:

Take advantage of the "Collection Edit" dialog to show a list of checkboxes with every storage class available.
The dialog should not allow zero classes to be selected.

The storage_classes_desired list will be displayed on the properties attribute panel as shown on the mockup. It will also appear on the collapsible "Info panel".

I think this should be enough as the storage classes aren't something that might be edited frequently so it doesn't need a more agile UI.

This is good. My only suggestion is that it should enforce that at least one storage class has to be checked, so you can't uncheck the last one.

• eb83305eb - branch 17573-export-storage-classes (arvados repo)
• arvados-workbench2|8df73e82 - branch 17573-edit-storage-classes (wb2 repo)
  Test run: developer-tests-workbench2: #448

Arvados repo updates¶

• Exports Volumes.*.StorageClasses.* configs.
• Adds default, foo and bar storage classes to arvados-server's test mode: it was generating 'Volumes.*.StorageClasses = null' configs.

Workbench2 repo updates¶

• Loads Volumes.*.StorageClasses.* exported configs into the store and provides a function that returns a list of all the available classes in the cluster.
• Displays collection's storage_classes_desired array on the collection main & details panels.
• Adds generic redux-form compatible "multi checkbox field" component.
• Uses the above-mentioned component in the "Edit Collection" dialog, enforcing at least 1 storage class to be always selected.
• Adds integration tests

To be discussed¶

• I first tried to add custom Volumes.*.StorageClasses configurations to the arvados_config.yml file that we have on wb2's repo for this purpose, but arvados-server doesn't seem to be loading them, so that's why I also added them on arvados-server's code. (I left them on the YAML file just in case there's a bug on the config loading code)
• RailsAPI currently allows a collection to have a storage class that doesn't exist on the cluster's configuration. I guess this is needed for those cases where a storage class is decommissioned or renamed. Currently, workbench2 doesn't render those classes as checkboxes on the "Edit Collection" dialog, so it isn't possible to remove them unless the user/admin uses the CLI tools. If this is not the appropriate UX behavior, we should come up with something that makes more sense.

Lucas Di Pentima wrote:

Updates at:

• eb83305eb - branch 17573-export-storage-classes (arvados repo)
• arvados-workbench2|8df73e82 - branch 17573-edit-storage-classes (wb2 repo)

To be discussed¶

• I first tried to add custom Volumes.*.StorageClasses configurations to the arvados_config.yml file that we have on wb2's repo for this purpose, but arvados-server doesn't seem to be loading them, so that's why I also added them on arvados-server's code. (I left them on the YAML file just in case there's a bug on the config loading code)

Hmm, it is a little surprising that workbench2/tools/arvados_config.yml doesn't work. Possibly the test server just overwrites and ignores the volumes section?

• RailsAPI currently allows a collection to have a storage class that doesn't exist on the cluster's configuration. I guess this is needed for those cases where a storage class is decommissioned or renamed. Currently, workbench2 doesn't render those classes as checkboxes on the "Edit Collection" dialog, so it isn't possible to remove them unless the user/admin uses the CLI tools. If this is not the appropriate UX behavior, we should come up with something that makes more sense.

I think that's fine. In the migration case the admin would need to do bulk migration anyway. I don't think people will manually change storage classes on individual collections very often.

One comment, rest LGTM:

The getStorageClasses() method should always add "default" to the list.