Skip to content

ROADMAP.md

Latest commit

 

History

History
144 lines (115 loc) · 9.37 KB

ROADMAP.md

File metadata and controls

144 lines (115 loc) · 9.37 KB
Raw

Storage Module Roadmap

Current Status

Production-capable storage runtime exists for durable persistence, MVCC/WAL lifecycle behavior, backup/PITR flows, blob/tiering behavior, and storage audit/integrity surfaces.

In Progress

  • [~] hardening failure-path behavior under sustained write/load and maintenance overlap (Target: Q3 2026)
  • [~] improving diagnostics consistency across storage, replay, and recovery stages (Target: Q3 2026)
  • [~] stabilizing benchmark-backed release guardrails for storage hot paths (Target: Q3 2026)
  • BLOCK 3: Storage Module Integration with AccessCoordinator (Target: Q4 2026) ✅ COMPLETE
    • Added PromotionListener support to TieredStorageManager
    • Added setPromotionListener() method in header and implementation
    • Emit onStorageAccess() signals when detecting hot tiers
      • emitPromotionEvent() helper method
      • Hot pattern detection in get() for WARM/COLD tiers
      • Hot pattern detection in runMigrationCycle()
    • Implement predictive promotion callbacks with access window tracking

Planned Features

Short-term (3-6 months)

  • integrate with AccessCoordinator for unified cache-storage tier management (Target: Q4 2026)
    • Add PromotionListener callbacks to emit hot-access signals to coordinator
    • Implement coordinator-guided promotion paths (cold→warm→L3)
    • Extend TieredStorageManager with coordinator hooks
    • See: src/access_model/ROADMAP.md Phase 4
  • tighten deterministic behavior under heavy WAL replay and compaction pressure (Target: Q4 2026)
  • expand stress coverage for blob/tiering and PITR edge scenarios (Target: Q4 2026)
  • improve operator-facing diagnostics for recovery and maintenance incidents (Target: Q4 2026)

Mid-term (6-12 months)

  • re-baseline p95/p99 envelopes for write/replay/recovery-sensitive paths (Target: Q1 2027)
  • broaden benchmark depth for mount-latency and storage allocator edge paths (Target: Q1 2027)
  • harden long-run reliability under sustained mixed read/write pressure (Target: Q1 2027)

Distributed Maturity Phase 3 — Track 2 Items (Q3–Q4 2026)

These items are part of the next-phase Track 2: Distributed Systems Maturity — 3.4 Storage plan (see ROADMAP.md §Track 2). Hard gate per item: deterministic under-load benchmark + release_critical CI green.

  • Tiered storage (hot/warm/cold) with automatic data migration: implement age- and access-frequency-based tier migration; data that has not been accessed within a configurable window automatically demoted from hot (NVMe) → warm (HDD) → cold (object storage) (Target: Q4 2026)
    • Inputs: tier policy config (storage.tier.hot_max_age_s, storage.tier.warm_max_age_s, storage.tier.cold_backend); access-frequency tracker
    • Acceptance: migration runs without blocking foreground I/O; cold-to-hot promotion completes within 100 ms for objects ≤ 1 MB; storage_tier_migration_total counter wired; release_critical green
  • Cloud-native S3/GCS/Azure backend hardening: harden the existing cloud backend adapter for sustained production use: retry with exponential backoff, integrity checksums (MD5/CRC32C), multipart upload for objects > 100 MB, SDK version pinning (Target: Q4 2026)
    • Acceptance: 72-hour soak at 1 000 object writes/s with zero data-integrity errors; multipart upload tested for 1 GB object; SDK versions pinned in vcpkg manifest

Implementation Phases

Phase 1: Design / API Contract

  • Freeze storage module API contract — WAL durability, MVCC snapshot isolation, crash-recovery, backup/PITR, tiering transparency, error taxonomy (include/storage/storage_api_contract.h) (Target: Q3 2026)
  • Define explicit StorageErrorCode taxonomy (WAL_WRITE_FAILED, CHECKPOINT_FAILED, RECOVERY_INCOMPLETE, PITR_INVALID_TIMESTAMP, COMPACTION_ABORTED, STORAGE_EXHAUSTED, …) (Target: Q3 2026)

Phase 2: Core Implementation

  • complete hardening for WAL/MVCC and backup/PITR internals (Target: Q4 2026)
  • align tiered/blob/redundancy behavior to bounded runtime contracts (Target: Q4 2026)

Phase 3: Error Handling and Edge Cases

  • standardize fail-safe behavior for replay faults, storage pressure, and recovery errors (Target: Q4 2026) ✅ COMPLETE (2026-08-03)
    • Created storage_error_diagnostics.h/cpp with unified error classification
    • Implemented storage_recovery_fault_handler.h/cpp for recovery fault handling
    • Implemented storage_pressure_manager.h/cpp for capacity management
    • Created comprehensive Phase 3 focused tests (24 test cases)
  • unify diagnostics across persistence, maintenance, and recovery incident classes (Target: Q4 2026) ✅ COMPLETE (2026-08-03)
    • StorageErrorContext struct for detailed error information
    • emitDiagnosticEvent() for structured event emission
    • Incident type classification (RECOVERY_FAULT, STORAGE_PRESSURE, etc.)
    • Error severity levels (INFO, LOW, MEDIUM, HIGH, CRITICAL)

Phase 4: Tests

  • Contract-hardening focused tests STR-01..STR-16 covering WAL durability, MVCC isolation, crash-recovery, and PITR invariants (tests/storage/test_storage_contract_hardening_focused.cpp) (Target: Q4 2026)
  • Expand focused regressions for replay, PITR, and tiered/blob edge scenarios (Target: Q4 2026)
  • Extend deterministic stress fixtures for mixed write + maintenance workloads (Target: Q4 2026)

Phase 5: Performance and Hardening

  • Lock benchmark-backed release gates for storage hot paths: SGRG-01..SGRG-06 in benchmarks/storage/bench_storage_release_gates.cpp (WAL throughput ≥100k ops/s, MVCC read p99≤100µs, MVCC write p99≤500µs, checkpoint p99≤10ms, tiering decision p99≤50µs, compaction check p99≤100µs) (Target: Q4 2026)
  • Validate p95/p99 and throughput behavior against release baselines (Target: Q4 2026)

Phase 6: Documentation and Acceptance

  • core storage module docs aligned to source-verifiable behavior
  • roadmap/future planning separated from historical changelog entries
  • Contract header frozen: include/storage/storage_api_contract.h
  • Contract-hardening tests delivered: tests/storage/test_storage_contract_hardening_focused.cpp (STR-01..STR-16)
  • Release-gate benchmarks delivered: benchmarks/storage/bench_storage_release_gates.cpp (SGRG-01..SGRG-06)

Production Readiness Checklist

  • core storage surfaces documented and source-verified
  • module-level security and failure behavior documented
  • benchmark mapping documented in performance expectations
  • Contract header frozen: include/storage/storage_api_contract.h (Phase 1)
  • Contract-hardening tests: tests/storage/test_storage_contract_hardening_focused.cpp (Phase 4, STR-01..STR-16)
  • Release-gate benchmarks: benchmarks/storage/bench_storage_release_gates.cpp (Phase 5, SGRG-01..SGRG-06)
  • Benchmark CMakeLists registered: benchmarks/storage/CMakeLists.txt
  • Error diagnostics system: include/storage/storage_error_diagnostics.h (Phase 3)
  • Recovery fault handler: include/storage/storage_recovery_fault_handler.h (Phase 3)
  • Storage pressure manager: include/storage/storage_pressure_manager.h (Phase 3)
  • Phase 3 focused tests: tests/storage/test_storage_phase3_error_handling_focused.cpp (24 test cases)
  • remaining hardening tasks closed for durability/recovery edge paths
  • release benchmark stabilization complete

Known Issues and Limitations

  • runtime behavior depends on storage configuration, backend profile, and workload shape.
  • selected replay/recovery/tiering edge scenarios need continued hardening.
  • benchmark depth should continue expanding for advanced storage workloads.

Breaking Changes

No breaking storage contract planned. Any contract-breaking change requires migration notes and changelog entry before merge.

Program Execution Model — Wave Context

This module is a contributing module in the program-level Wave A → B → C → D execution model. It does not own a primary wave deliverable but must remain release_critical-green throughout all waves and must deliver Wave D operability improvements in Q1 2027. See ../../ROADMAP.md for the full wave model and exit criteria.

Wave D Contribution for storage

  • Deliver or validate distributed tracing, high-cardinality stress coverage, exporter reliability, and operator remediation hints as applicable to this module (Target: Q1 2027)
  • Contribute to or validate long-duration soak test coverage for this module's primary paths (Target: Q1 2027)
  • Ensure runbook coverage for operator-critical scenarios in this module (Target: Q1 2027)

Cross-Wave Requirements

  • release_critical CI must remain green on develop throughout all waves (Target: ongoing)
  • p95/p99 benchmarks must be refreshed on representative hardware before Wave D sign-off (Target: Q1 2027)
  • No behavioral regression may be introduced into modules in Wave A/B/C scope from changes in this module.

Program-Level Success Criteria (contribution)

  • This module's distributed/acceleration paths fail closed (Target: Q1 2027)
  • Benchmark-backed p95/p99 baselines exist on representative hardware (Target: Q1 2027)
  • Operator-critical paths have diagnostics, alerts, and runbooks (Target: Q1 2027)