More to the point, the comment in the code mentions the “combinatorial” explosion of conditions that have to be carefully maintained by fallible meat brains.
In most modern languages something like this could be implemented using composition with interfaces or traits. Especially in Rust it’s possible to write very robust code that has identical performance to the if-else spaghetti, but is proven correct by the compiler.
I’m on mobile, so it’s hard to read through the code, but I noticed one section that tries to find an existing volume to use, and if it can’t, then it will provision one instead.
This could be three classes that implement the same interface:
class ExistingVolume : IVolumeAllocator
class CreateVolume : IVolumeAllocator
class SeqVolumeAllocator : IVolumeAllocator
The last class takes a list of IVolumeAllocator abstract types as its input during construction and will try them in sequence. It could find and then allocate, or find in many different places before giving up and allocating, or allocating from different pools trying them in order.
Far more flexible and robust than carefully commented if-else statements!
Similarly, there's a number of "feature gate" if-else statements adding to the complexity. Let's say the CreateVolume class has two variants, the original 'v1' and an experimental 'v2' version. Then you could construct a SeqVolumeAllocator thus:
allocator = new SeqVolumeAllocator(
featureFlag ? new CreateVolumeV2() : new CreateVolumeV1(),
new ExistingVolume() );
And then you
never have to worry about the feature flag breaking control flow or error handling somewhere in a bizarre way.
See the legendary Andrei Alexandrescu demonstrating about a similar design in his CppCon talk “std::allocator is to allocation what std::vector is to vexation”: https://youtu.be/LIb3L4vKZ7U