fix(scheduler): parse fractional and Pi/Ei resource quantities - #87

Summary

Fixes #86.

parse_resource_quantity parsed the digits of a suffixed quantity with str::parse::<i64>(), so every resource.Quantity carrying a decimal point silently fell back to unwrap_or(0). The upstream grammar in k8s.io/apimachinery/pkg/api/resource/quantity.go allows a decimal point with every suffix:

<number> ::= <digits> | <digits>.<digits> | <digits>. | .<digits>

so "0.5Gi" is as valid as "512Mi" and denotes the same 536870912 bytes.

Parsing it as 0 does not fail loudly — it reads to the scheduler as "this pod requests no memory", so the pod is admitted to any node regardless of remaining capacity. The same unwrap_or(0) applies to node allocatable, so a node advertising "1.5Ti" is accounted as having no memory at all and nothing schedules onto it.

Pi and Ei were missing from the binarySI set entirely and fell through to the same 0.

Verified against resource.ParseQuantity(s).Value() from k8s.io/[email protected]:

Fix

Replace the hand-rolled strip_suffix chain with a QUANTITY_SUFFIXES table applied over an f64 parse:

• Ordered longest-first, so "1Mi" cannot be read as "1M" followed by a stray i.
• Bare numbers and the <decimalExponent> form are parsed directly first. Rust's float parser implements that production exactly and rejects "1E"/"1Gi", which then fall through to the table — so "129e6" stays 129000000 while "1E" still means exa.
• Pi and Ei added to complete binarySI.
• Non-finite input ("inf", "NaN", "1e400") is rejected instead of saturating to i64::MAX, which would otherwise advertise infinite node capacity.
• CPU folds into the same path rather than needing a special case: m is the shared 10^-3 decimalSI suffix, so "100m" is 0.1 cores → 100 millicores. Result is rounded so "0.7" cores stays 700m.

scheduler.rs carried a byte-identical copy of the same function. It now imports the fixed one from advanced.rs instead of maintaining a second copy (net −93 lines there).

Behaviour for every input the previous implementation handled correctly is unchanged; the existing test_parse_cpu_quantity and test_parse_memory_quantity cases pass untouched.

Tests

Five new cases in crates/scheduler/src/advanced.rs:

• test_parse_fractional_memory_quantity — 0.5Gi, 1.5Gi, 0.5Mi, 2.5Mi, 0.5Ki, 1.5G, 0.5M, 1.5k
• test_parse_large_binary_suffixes — Ti, Pi, Ei
• test_parse_decimal_si_and_exponent — 1T/1P/1E/1k, plus 129E6 and 1.5e3 as exponent forms
• test_parse_cpu_fractional_and_milli — 100m, 1500m, 0.7, 2.5, 10.5m
• test_parse_quantity_rejects_malformed_input — "", "abc", "Gi", "1Xi", "--5", "inf", "NaN", "1e400" all yield 0

Test plan

• cargo test -p rusternetes-scheduler — 27/27 pass (was 22)
• cargo test --workspace — 4209 passed, 0 failed (baseline on main: 4199 passed, 0 failed; +10 is the 5 new tests across the crate's lib and bin targets)
• cargo fmt --all -- --check clean (checked over workspace members, as .github/workflows/fmt.yml does)
• cargo clippy -p rusternetes-scheduler --all-targets --all-features — no new warnings; the only hits in the touched files are the pre-existing check_preemption / SYSTEM_CRITICAL_PRIORITY dead-code warnings