Currently volume types are used for two main purposes: for the capability filter scheduler to decide where to place volumes, and for drivers to create volumes with certain parameters/capabilities.
It is important for volume types to be both standardized and flexible. For example, if two different back-ends support feature foo, then they should report it in the same way. The scheduler should choose either back-end, and that back-end should have a key to enable feature foo for the given volume.
We propose to: - Maintain a list of mandatory capabilities that all drivers must report (one current example is free space). These capabilities must be generic and make sense for all back-ends. - Maintain a list of recommended capabilities that drivers may report. These should still be generic, but well-defined, and used across back-ends. - Drivers may report any additional capabilities that they want where they are specific to that back-end. - Administrators should be able to specify capabilities for storage via the configuration file if the driver doesn't report them.
The goal of this session is to discuss the mechanisms for managing capabilities (e.g., proposing new ones, listing existing ones), and perhaps to come away with an initial list.