Adjust defaults to better handle self-hosting and bootstrapping #19190
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: smarterclayton The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
approved
|
This blocks landing static pods because atomic has only one core and can only run 10 pods on the master. |
|
/test install |
|
/test extended_conformance_install |
What value does that have over floating like upstream does? We hit a situation where it was better to not have this value. Why is it better to do this than to be consistent with upstream? Just the question. lgtm otherwise. |
|
I'm thinking about the true pathological cases where we let the limit off and someone suddenly gets "max-pods" scheduled. With this change and the defaults that would be at 6 cores, whereas with no defaults it could happen on 1 core. I'm neither strongly for or against, so your call |
A single core master may run up to 25 pods before too long. This limit was intentionally low in the early days where stability was an issue. At this point it is no longer helpful and should be increased.
We plan on using long durations for when auto-approve is off and short durations (<1d) for when they are on. A month was too far from either extreme.
|
Removed, david convinced me we should do what upstream does wherever possible. |
smarterclayton
added
lgtm
@deads2k as discussed although I bumped the default for pods-per-core rather than removing.