capistrant commented on PR #18599: URL: https://github.com/apache/druid/pull/18599#issuecomment-3628406005
> Thanks for the update, @capistrant ! The changes look good. > > The blocking comments are only these: > > * [#18599 (comment)](https://github.com/apache/druid/pull/18599#discussion_r2599314643) (is `DruidKubernetestCachingClient.stop()` called upon loss of leadership? Should we also have a `start()` which is called on becoming leader?) > * [#18599 (comment)](https://github.com/apache/druid/pull/18599#discussion_r2599334679) (when do we call `podInformer.run()` in `DruidKubernetesCachingClient`? > > The other comments are all minor suggestions. Thanks @kfaraz for another review round. I think that these questions are both inter-mingled actually. How everything works now, the Informers start automatically when `DruidKubernetesCachingClient` is created. This is happening as a part of the overlord startup, regardless of leadership. The `start()` calls on the informers in the tests were benign and I removed them. The above information leads to your other question on when to call stop. Right now we only call stop as a part of the JVM lifecycle and not on loss of leadership. This is because as currently constructed the informers are started and exist for the lifecycle of the jvm so they are active regardless of if an OL is leader. I think the key question is, do we want the informer/caching client to be tied to the JVM lifecycle as they are now or tied to leadership state. doing the latter would reduce resource required by the standby in exchange for lengthening failover time (I'm not exactly sure on statistics here regarding how long failover would be extended by. It would scale with the pod count in k8s, but I don't have any good estimate on what that looks like for a k8s cluster with 500 pods, 5000 pods, 50000 pods, etc) -- 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]
