Custom scoring system for drivers

[chrboe]

I suppose this is a request for discussion about the general idea/design behind Stork.

The way I understand it, volume drivers in Stork are essentially responsible for querying all relevant volumes in the system and ordering them by "priority". The only mechanism for "priority" that is currently exposed is the "Rack/Zone/Region" logic, where a volume driver can give Stork information about the physical location of a volume. The actual score is then calculated deep in the Stork code.

This is one good measure, but I think there are many more factors to take into account rather than just physical location.

What about local disk performance? For example, LINSTOR has a concept of a replica being "diskless" – which means that a node does not have a physical disk for a volume, but rather sends the read and write requests directly over the network to another node. Obviously, this is much slower, so we would want to de-prioritize these nodes.

Or what about the number of replicas? Arguably, a node that has two replicas of a volume is a better candidate than a node that only has one.

LINSTOR actually exports a metric that expresses exactly that: the promotion score. From the documentation:

Every DRBD resource exposes a promotion score on each node where it is configured. It is a numeric value that might be 0 or positive. The value reflects how desirable it is to promote the resource to master on this particular node. A node that has an UpToDate disk and two UpToDate replicas has a higher score than a node with an UpToDate disk and just one UpToDate replica.

During startup, the promotion score is 0. E.g., before the DRBD device has its backing device attached, or, if quorum is enabled, before quorum is gained. A value of 0 indicates that a promotion request will fail [...]

We could forward this score directly to Stork in order to get very precise and smart scheduling decisions.

So, are there currently any plans to support a custom scoring system for volume drivers? I think this would be a valuable feature to take into consideration.