[numinnex]

No description provided.

[hubcio]

we're dropping purge, removal pr goes up today. so purge_generation can come out of the key layout and the marker. same for the purge invariants and the "purge during an upload" row. i think created_revision is enough on its own since offsets can't restart anymore, wdyt?

[djanand]

@hubcio @numinnex thanks, read through this against master. Agree with the direction: keep the replicated local log as the write path, copy sealed segments out after, one replica uploads and tells the others an offset, stubs keep offset lookups off the network. A couple of questions/observations that I had

1. Phases. The plan reads as a chain, but it looks to me like phases 1 and 3 don't depend on each other and only phase 2 is blocked on the partition state-machine RFC, with 4 and 5 behind it. Is that right? Is the phase 2 RFC on partition state-machine drafted anywhere ?
2. The age roll in phase 5: There's a version that I think needs no new consensus operation seal when the arriving batch's timestamp is more than segment_max_age past the segment's first timestamp. Both are assigned by the
   primary and replicated unchanged, so every replica seals at the same message and segments stay identical. It covers slow-but-steady and long-gap traffic, leaving only a fully idle partition for the replicated roll. Is segment_max_age gated on tiered_storage being on? It's listed with the tiered options. If it works on any topic it also fixes message_expiry on a topic that doesn't fill a segment.