Prevent over-provisioning #622
Conversation
Jenkins can keep on asking for more executors even though it has enough slaves promised to it that will satisfy demand once they come online. We already keep track of the number of slaves that we are in the process of creating but have yet to give to Jenkins, so if we include that count when determining demand, we can ensure we do not provision more containers than permitted.
|
@ndeloof I've not had much of a chance to test this beyond ensuring that it doesn't seem to do any harm ... but I think this is a pretty important stability enhancement. |
|
Personally I wasn't going to press the "merge" button on this until I was sure it was a good change, but I guess as long as we don't release it until we can be sure that it's all good then that'll suffice. |
|
|
|
OK, I'll take your word for it - personally I'm not hugely comfortable with git beyond "commit" and "push" :-) FYI I've added a few RFEs (#624, #625, #626) that I intend to start work sometime next month (probably in that order). If you have any opinions on them then please do share - I don't want to take things in a direction you disapprove of, and I'd also really value having a second opinion - it's all too easy to get "tunnel vision" and end up going down the wrong path sometimes... |
Jenkins can keep on asking for more executors even though it has enough slaves promised to it that will satisfy demand once they come online.
We already keep track of the number of slaves that we are in the process of creating but have yet to give to Jenkins, so if we include that count when determining demand, we can ensure we do not provision more
containers than Jenkins really wanted.
Note: This is mostly useful if the docker host is being slow at creating containers, causing Jenkins to ask again before we've created the last bunch.