IOLake roadmap¶
What comes next, by release. What already exists, and how far each part has been proven, is in features.md; what each release shipped is in its notes (0.1.0). When a release is cut, its items move into its notes and leave this page, so this page only ever shows what is ahead.
Each item is one line: what will be true when it is done, which is also how it is tested. Moving an item between releases is an edit to this page, in a pull request like any other change. Each item links to its GitHub issue, and the IOLake project shows which are in progress.
Last reviewed: 2026-10-20, after an external production-readiness review of the release candidate.
Priorities¶
- S3: production-ready and bug-free. The product we ship first. No known bug stays open; every gap is either closed or written down as "not supported" with the reason.
- The storage engine core, worked on alongside S3: OSD, erasure coding, placement, meta, repair. Everything here is built once and reused by block and file; none of it is S3-specific.
- Data lake (Iceberg REST, Unity Catalog, Delta Sharing): next, and as important as S3 once S3 is in production.
- Block, then file, on the same core.
Rule for every domain: reliability first. An acknowledgement means the data is on stable storage; nothing trades durability for speed.
Domains¶
Every item, feature and design belongs to one domain; the names are the
same everywhere (this page, features.md, the designs, and
the area: labels on issues).
| Domain | What it covers |
|---|---|
| S3 | The S3 API and what is built on it: buckets, objects, versioning, lifecycle, replication, audit, Select, logging, quotas |
| Core | The storage engine shared by object, block and file: OSD, erasure coding, placement, meta (Raft), repair, recovery |
| Data lake | Iceberg REST Catalog, Unity Catalog API, Delta Sharing |
| Security | IAM, STS, tenants, policies, authentication, encryption and KMS, TLS between services |
| Block | Block volumes (NBD, gRPC) |
| File | File access (NFS and others) |
| Platform | Install and operate: Helm, iolake-aio, console, CLI, SDKs, metrics, dashboards, the release |
Status legend¶
| Mark | Meaning |
|---|---|
| ✅ | Shipped and covered by end-to-end tests |
| 🟡 | Shipped, but not yet proven for production (the gap is named) |
| 🔨 | In progress |
| ⬜ | Planned |
| ✖ | Not supported, by decision (reason given) |
0.1.0: the first release (release candidate)¶
The release candidate passed every gate (the release notes have the evidence). These close it out before 0.1.0 is final.
| Item | Domain | Design | Guide | Issue |
|---|---|---|---|---|
| Meta's memory over the 48 h soak (from about 37 MB to 190–340 MB, 498 MB at the peak) explained by a heap profile, and fixed or bounded | Core | meta | profiling | #3 |
| The chaos partition fault's write pause (13.2 s, against 5.4 s on 2026-10-04) explained, and brought back or its cause written down | Core | meta | chaos | #4 |
| Format level 8 is the first release's baseline: the lowest level a binary runs at is 8, and the code paths for the levels below it (development builds) are removed; verified by the end-to-end suite and a chaos run (built; the chaos run is with the rc.3 soak). Each release candidate upgrades to the next one node at a time (0.1.0-rc.2 to rc.3, and the last rc to 0.1.0): adjacent releases only, as for every release | Core | upgrade path | upgrades | #6 |
| Release notes reviewed; the 0.1 version of the site and the release's binaries, image and chart published | Platform | — | 0.1.0 | #7 |
0.2.0¶
| Item | Domain | Design | Guide | Issue |
|---|---|---|---|---|
Engine tests in CI: pyiceberg creates, appends to, reads and time-travels a table against iolake-aio |
Data lake | — | Iceberg API | #8 |
| Spark and Trino run the same scenarios through the REST catalog, with SigV4 and with OIDC, on vended credentials | Data lake | — | Iceberg API | #9 |
| Concurrent commits: many writers to one table lose no commit, and a conflict is refused cleanly | Data lake | — | — | #10 |
| Policies seen by an engine: namespace and table denies, row filters and column masks | Data lake | — | — | #11 |
The delta-sharing Python client reads shared Delta tables (a share refuses Iceberg tables) |
Data lake | — | feature reference | #12 |
| A tenant's audit events into a bucket of its own: turned on by the tenant admin, only its own events, within a minute, none missing after a gateway crash | S3 | — | audit | #14 |
| Audit export (a time range, by API and console download) and a console search page, both limited to the caller's tenant | S3 | — | audit | #15 |
| Audit to Kafka at least once; a removed or altered event detected by a hash chain | S3 | — | audit | #16 |
| Test what we ship: the end-to-end suite and the soak run on the release build's features (io_uring; ISA-L is in every build) (🔨 the data-path end-to-end files run on them in CI) | Core | I/O levels | — | #17 |
| Every protection scheme through the same tests as 4+2: LRC and 2- and 3-way replica pools (loss, repair, drain) and a soak with them (🔨 repair for both built and tested) | Core | data protection | — | #18 |
| Drive power-safety checks: each OSD reports per drive whether it has power-loss protection or a volatile write cache (metrics, console) | Core | storage engine | production | #19 |
| Repair throughput: a replaced 7.68 TB drive of 1 MiB objects rebuilt in under 8 hours on the lab host, client I/O keeping priority (🔨 10 → 67 shards/s, PG counts sized from the drives) | Core | PG recovery | hardware sizing | #20 |
| Profiling pass on the hot paths: GETs, a drive's rebuild and listings, after the 64 KiB PUT (🔨 pass 1 done) | Core | — | profiling | #21 |
The Helm chart wires the gateway to Prometheus (--prometheus-url) and can add a ServiceMonitor |
Platform | — | monitoring | #61 |
| A tenant admin appends to an Iceberg table on vended credentials | Data lake | — | Iceberg API | #66 |
The console's Delta Sharing profile works with the delta-sharing client unchanged |
Data lake | — | — | #67 |
| Host maintenance without a full backfill: a noout flag and maintenance mode, and no automatic stand-ins when a whole host or rack is down | Core | PG recovery | failure recovery | #82 |
| Orphaned shards reclaimed: a gateway crash mid-PUT leaks nothing for good; incomplete uploads expire by default | Core | — | — | #83 |
| Tail latency: writes return at quorum, stripes pipelined, reads hedged, coding off the async runtime | Core | — | — | #84 |
| Data lake correctness: warehouse-scoped keys for every table call, metadata beyond 4 MiB, caches refreshed on every node, metadata files written to S3 | Data lake | — | Iceberg API | #85 |
| Block volumes: acknowledged writes survive the loss of the gateway's node, exclusive attach, a bounded journal, chunks on the volume's pool | Block | block storage | — | #86 |
| A meta restore rebuilds pack records and the shared-stripe registry from the OSDs, so packed objects read after it | Core | meta | failure recovery | #100 |
Later¶
| Item | Domain | Design | Guide | Issue |
|---|---|---|---|---|
| Bucket replication, two-way (active-active) | S3 | bucket replication | replication | #22 |
| Bucket replication to targets that aren't IOLake, best effort | S3 | bucket replication | — | #23 |
| Bucket notifications (webhook, Kafka, AMQP) | S3 | — | — | #24 |
| Rate limits per bucket and per tenant | S3 | — | — | #25 |
| S3 Vectors (planning only) | S3 | planning | — | #26 |
| FTP, FTPS, WebDAV and Swift gateways, as migration aids | S3 | topology | — | #27 |
| SSE-C on a CopyObject source or destination | Security | — | — | #28 |
| KMS key rotation and key states | Security | — | — | #29 |
| Re-encrypting CopyObject streamed, not buffered in memory | Security | — | — | #30 |
| External KMS (AWS KMS, Vault) | Security | — | — | #31 |
| mTLS certificates reloaded without a restart | Security | — | mTLS | #32 |
| Placement honours failure domains, always: a pool whose topology can't spread k+m across its failure domain refuses writes with a clear error (validation endpoint built) | Core | topology | — | #33 |
| Domain drain: a host or rack drained under traffic, repair sourcing from outside it | Core | topology | — | #34 |
| Repair bandwidth budget per topology link, client latency kept | Core | topology | — | #35 |
| Network-fabric awareness (pod, ToR, RDMA group; client hints) in read and rebuild source choice | Core | topology | — | #36 |
| Rack-local LRC: a rack's loss rebuilt from inside the rack (🔨 groups kept per rack and rebuilt from inside the group) | Core | topology | — | #37 |
| Dedup, phases 2–4 (🔨 phase 1: policy and dry run) | Core | dedup | — | #38 |
| Compression: zstd per object before erasure coding, by policy | Core | — | — | #39 |
OSD engines behind interfaces: ShardTransport after MetaIndex and ShardStore (🔨) |
Core | OSD engines | — | #40 |
| RDMA data plane beyond single-part erasure-coded objects, and on by default | Core | RDMA data plane | — | #41 |
| Ceph (RADOS) as an optional data backend, for sites that already run Ceph; IOLake's own engine stays the default | Core | — | — | #42 |
| Delta log checkpoints (Parquet) | Data lake | — | — | #43 |
| Catalog at scale: thousands of tables, large metadata files, through a meta failover | Data lake | — | — | #44 |
| Block crash consistency: ext4, xfs and PostgreSQL on NBD, the gateway killed mid-write, fsck and database recovery clean (the gate for production) | Block | block storage | — | #45 |
| Block QoS: per-volume IOPS and bandwidth limits hold under contention | Block | block storage | — | #46 |
| iSCSI or NVMe-oF: one standard initiator attaches and passes the crash tests | Block | block storage | — | #47 |
| File: a design (namespace model, rename, locking) on the shared core, then an NFS v3/v4 gateway | File | — | — | #49 |
| SMB, FUSE | File | — | — | #50 |
| Grafana dashboards and alert rules in the Helm chart, not only the docker-compose stack | Platform | — | monitoring | #51 |
| OpenTelemetry tracing | Platform | — | — | #52 |