Feature #17696
Updated by Ward Vandewege over 2 years ago
Use case: the default storage classes should be configurable in the config file, and there can be more than one. * api/controller reads Collections/DefaultStorageClasses map[string]bool. The default value should will be {"default":true} (aka one storage class named "default"). * out of the box, if Collections/DefaultStorageClasses is empty, and Volumes/XXXX/StorageClasses is empty, the implied value for both of those is "default". This should be done as part of config load. Using config-dump will show these "default" values. The config on the website will just have this listed in the comments, not in the sample config file. * when new collections are stored (and no storage classes are requested) the default values should be added to the desired storage classes * update those clients that send "default" as the storage class to send nothing instead * need a migration? for existing collections with storage class "default". Add a python recipe to the cookbook to change a particular storage class (e.g. "default") to something else. * add some tests * validation on the config-check: - config check. Make sure the default class(es) are implemented by a volume. - If the config mentions an explicit storage class on a volume, all volumes must have storage classes defined (warning or error?) and Collections/DefaultStorageClasses must be set explicitly. This gives us a short configuration (nothing set) that implies "default" in the simple case, but as soon as someone adds an additional storage class, we protect them from mistakes by forcing them to be explicit about all the storage classes in use. * add some tests