Chaer
Chaer
> @Eikykun Yeah, that would be a serious problem. Maybe a tricky solution: > > 1. Return a `StatusNotFound` for leaderelection Get. > 2. Return a mock success for leaderelection...
> Just wondering if the client-go's `workqueue` ensures that no more than one consumer can process an equivalent `reconcile.Request` at any given time, why don't we clear the related informer...
> > According to #715, the root cause is the stale informer cache, so I am wondering if the issue can be solved by fixing the cache, for example doing...
> Btw, @Eikykun would you mind rebasing with the master branch and resolving the conflict? Thanks! thanks for your review, I will review the pr issue and resolve the conflicts...
> At a quick glance, it seems that we create an ActiveExpectationItem for each Pod's creation, deletion, or update. I have some concerns about the scalability bottleneck caused by the...
Could you help approve the workflow? cc @kevin85421 If there are any questions, concerns, or additional changes needed on my part, please let me know. I am happy to assist...
> A few questions I'd like to ask: > > * Is `ExpectedResourceType = "RayCluster"` actually used? So far, I've only seen "Pod" being used. > * Your implementation and...
> By the way, maybe you missed this because this comment is folded. [#2150 (comment)](https://github.com/ray-project/kuberay/pull/2150#discussion_r1843097987) > > Could you either: > > * Change the `ExpectScalePod` to return an error,...
@kevin85421 Can you merge the PR?