Closed smoy closed 1 year ago
There are environment variables that can tell whether you are running in a github workflow or not. Instead of changing the ulimit, I'd suggest lowering the resource consumption by default. That could be as simple as changing the connection pool size when instantiating the clients. I think it is plenty fast, so lowering it to work with the constraints of the OS defaults makes sense vs. trying to change the ulimit. If it is running in github, you could automatically raise the size of the connection pool based on it detecting it is running in a runner, or make it a command line flag.
That's good suggestion. I think we need a refactor the current boto3 client logic across AWS accounts. The implementation today assume it gets a client, open a file, it will succeed. There is no resource manger interface or queue on the interfaces. I will write up a feature enhancement proposal how we want to do it.
What I mean by that is if the host process has only N available fd. The implementation does not really take it into consider, if it needs N+1 FD, it will just crash.
I open https://github.com/noqdev/iambic/issues/391 to track the work required to refactor the implementation.
https://github.com/noqdev/iambic/pull/387 addressed the user experience, so user is not fighting ulimit. But #391 should get looked at to play nice with resource limit.
Describe the bug macOS default
ulimit -n 256
is a problem when an AWS org contains a lot of accounts.To Reproduce Steps to reproduce the behavior:
ulimit -n 256
in your environment. Since IAMbic use multiprocessing, you should ensure your shell is not changing the ulimit value.Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context Current workaround requires you to change your ulimit