goutamadwant commented on issue #7634: URL: https://github.com/apache/kyuubi/issues/7634#issuecomment-5657697247
@ruanwenjun I'd like to work on this. I traced the current cleanup path, including the informer ADD handling from #7632 and the pinned Fabric8 deletion behavior. The proposed scope is: - Keep informers, audit/metadata updates, and local application-info expiry on every server. Separate the retryable pod-deletion queue from local cache eviction so cancellation or shutdown cannot trigger deletion through the removal listener. - Coordinate only terminated-driver cleanup. Leave explicit cancellation and the orphan-pod work in #7620 unchanged, and preserve the existing `NONE`, `ALL`, and `COMPLETED` policies. - Reconcile after ownership acquisition and informer synchronization; stop starting deletes after observed ownership loss. Suppress already-deleting/deleted candidates, protect against same-name replacement pods, and distinguish an accepted DELETE or named-resource 404 from real failures. Transient failures would use bounded backoff. This would not promise exactly-once requests across failover. Could you confirm three design choices before implementation? 1. Add a cleanup-ownership lifecycle with renewal/loss handling for ZooKeeper and etcd, rather than reuse `tryWithLock` as a long-lived leader flag. Its etcd lock lease is not renewed during the callback. Preserve standalone behavior; loss of configured HA ownership should pause coordinated deletion. 2. Key ownership by the resolved Kubernetes API endpoint and namespace within the HA namespace, with matching cleanup policies across candidates, rather than host-local context aliases alone. 3. On takeover, conservatively restart the retention interval for candidates without a known deadline, avoiding a new persisted-deadline mechanism in the first patch. Is that additional failover delay acceptable? Tests would cover two-server contention/failover, follower cache expiry, retention policies, deletion events/finalizers, stale pod identity, and failed-request recovery without requiring a real cluster. Does this match the intended scope? Disclosure: AI was used to understand the codebase and review the code. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
