Connection limit for thick daemon.

[juliusmh]

Signed-off-by: Julius Hinze [email protected]

[dougbtv]

Julius -- quick question: what's the difference between #1347 and this one? Could we put them together? Thanks! Went to review #1347 and then saw this one as well

[coveralls]

coverage: 56.403% (-0.05%) from 56.454%
when pulling 76b048b on juliusmh:jmh/limit_listener
into 781ecda on k8snetworkplumbingwg:master.

[juliusmh]

Julius -- quick question: what's the difference between #1347 and this one? Could we put them together? Thanks! Went to review #1347 and then saw this one as well

Sure. Let's proceed here.

[juliusmh]

@dougbtv is this PR still considered? Is there anything I can do from my end to help get this merged?

[JensErat]

This resolved heavy OOM issues in a cluster running a larger 2-digit number of pods with multus enabled. Rebooting a node reproducible forced multus into an OOM loop, stopping all pods from running. I'd propose to additionally either add this to the configuration or even set a reasonable default value (I was randomly choosing 5).

@dougbtv does this have any chance of getting merged? Currently, we're considering whether we'll have to run a forked copy.

[github-actions]

This pull request is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[juliusmh]

Not stale

[sunjayBhatia]

Hey @dougbtv @juliusmh we're also running into #1346 and this looks like a good candidate to help with multus+delegate CNI pod resource usage

Is there anything here we can help with that is left to do? some e2e test coverage?

[JensErat]

@dougbtv @juliusmh this is still important

[juliusmh]

Reopening in #1437.

[netcho]

Why is this PR closed without any mention of how to fix/workaround the scenario described?