SEZ9 commented on issue #12886: URL: https://github.com/apache/seatunnel/issues/12886#issuecomment-6356526686
@goutamadwant thanks for turning the PoC into concrete PRs, and for splitting the bounded-file recovery fix (#12942) out as a prerequisite rather than folding it into the HA change. Agree with @nzw921rx that reusing the native Zeta election, backup and recovery paths is the right direction for this follow-up to STIP-41 instead of inventing a K8s-side recovery model. Before we go deep on #12943, a few things I'd like to see captured in the STIP follow-up under #11857 so the review of the PR has a fixed contract to check against: 1. **Ownership / controller graph** – with the owner/observer Job plus master/worker StatefulSets, which resource is authoritative for the Kubernetes application ID, who owns the StatefulSets and the Service, and how normal completion, cancellation and partial startup clean them up while still preserving user-owned checkpoint storage. 2. **Active-master handoff** – how the stable endpoint resolves to the live master after replacement, how status/cancel locate it, and how a replaced/exiting master is prevented from running the normal terminal cleanup path. 3. **Supported failure model** – please state it exactly as you did here: sequential Pod loss with accessible durable checkpoints. Node/storage outages, loss of quorum and partition/fencing safety stay out of scope until separately specified and tested; the PR description and docs shouldn't imply the PoC covers them. 4. **Configuration contract** – where HA replica count and `backup-count` are validated and what pre-submission errors users get for invalid combinations. 5. **Reproducible matrix** – manifests, commands, expected status/cancel behaviour, checkpoint-restore evidence, record-integrity check (the 480-ID LocalFile run is a good template) and cleanup assertions for active-master, standby-master, worker and owner-Pod loss. Single-node K3s is fine as the baseline; please also note that multi-node behaviour is unvalidated. 6. Keep PostgreSQL fencing as its own follow-up, as you proposed. Once that write-up is linked from this issue, I'll go through #12943 against it. @nzw921rx, if you have time to look at items 1 and 2 in particular, a second pair of eyes on the ownership and handoff contract would be very helpful. <!-- streview-comment:1969 --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
