t4lz

I see what you're saying. Just so we're on the same page: ``` { "feature": { "split_queues": { "whatever-q-splitter": {

So you want the operator to auto-detect the splitter resource based on the target's deployment/rollout? The operator would check which splitter resource has that deployment/rollout and use that?

> > So you want the operator to auto-detect the splitter resource based on the target's deployment/rollout? The operator would check which splitter resource has that deployment/rollout and use that?...

Yeah number 1 is reasonable (imo also 3 is good) - should we do it like our stealing policy: - you don't have to set a filter if you're the...

> * you don't have to set a filter if you're the first client to target a queue-consuming target. > I disagree on that, at least for the first version...

Why is that unsafe?

> on another note - how did you think to do the queue filtering? in the operator itself? Initially I thought we'd spawn a job/pod for it but then realized...

> ``` > apiVersion: v1 > data: > config.yaml: |- > queue_name: xx-queue-name > > ``` In this example from the original issue comment the queue name is defined inside...

Just so that we don't forget by the time we get to work on this issue: the point is to find the underlying race condition and eliminate it, not just...

> @t4lz This is a flake right? Only in the sense that it sometimes does not fail. There is an actual issue issue in mirrord (intproxy), not in the test....