Jenkins and plugins versions report
Jenkins: 2.542
OS: Linux - 6.8.0-1044-azure
Java: 17.0.18 - Ubuntu (OpenJDK 64-Bit Server VM)
---
antisamy-markup-formatter:173.v680e3a_b_69ff3
apache-httpcomponents-client-4-api:4.5.14-269.vfa_2321039a_83
apache-httpcomponents-client-5-api:5.6-191.vb_47e2b_41c698
asm-api:9.9.1-189.vb_5ef2964da_91
authentication-tokens:1.144.v5ff4a_5ec5c33
azure-ad:631.vb_2d4d8cc86b_0
azure-credentials:421.vb_ffd07e951a_2
azure-sdk:259.vf079c96088a_f
azure-vm-agents:1103.ve4a_50ca_2c617
bitbucket-push-and-pull-request:3.3.4
blueocean:1.27.25
blueocean-bitbucket-pipeline:1.27.25
blueocean-commons:1.27.25
blueocean-config:1.27.25
blueocean-core-js:1.27.25
blueocean-dashboard:1.27.25
blueocean-display-url:2.4.4
blueocean-events:1.27.25
blueocean-git-pipeline:1.27.25
blueocean-github-pipeline:1.27.25
blueocean-i18n:1.27.25
blueocean-jwt:1.27.25
blueocean-personalization:1.27.25
blueocean-pipeline-api-impl:1.27.25
blueocean-pipeline-editor:1.27.25
blueocean-pipeline-scm-api:1.27.25
blueocean-rest:1.27.25
blueocean-rest-impl:1.27.25
blueocean-web:1.27.25
bootstrap5-api:5.3.8-895.v4d0d8e47fea_d
bouncycastle-api:2.30.1.83-289.v8426fcd19371
branch-api:2.1280.v0d4e5b_b_460ef
build-with-parameters:
caffeine-api:3.2.3-194.v31a_b_f7a_b_5a_81
checks-api:402.vca_263b_f200e3
cloud-stats:377.vd8a_6c953e98e
cloudbees-bitbucket-branch-source:937.2.6
cloudbees-folder:6.1079.vc0975c2de294
commons-collections4-api:4.5.0-8.va_d5448ef9011
commons-compress-api:1.28.0-3
commons-lang3-api:3.20.0-109.ve43756e2d2b_4
commons-text-api:1.15.0-218.va_61573470393
configuration-as-code:2065.v7a_20a_b_d84088
copyartifact:795.ve8e151429b_27
coverage:2.3139.v731d2e83ea_8a_
credentials:1502.v5c95e620ddfe
credentials-binding:719.v80e905ef14eb_
cucumber-reports:5.10.2
data-tables-api:2.3.7-1534.v539d4edf109d
display-url-api:2.217.va_6b_de84cc74b_
docker-commons:472.vee120e23d3a_c
docker-workflow:634.vedc7242b_eda_7
durable-task:664.v2b_e7a_dfff66c
echarts-api:6.0.0-1247.vf3e35a_c1813f
eddsa-api:0.3.0.1-29.v67e9a_1c969b_b_
favorite:2.263.v941d21defef7
font-awesome-api:7.2.0-965.ve3840b_696418
forensics-api:3.1832.va_1179842528b_
generic-webhook-trigger:2.4.1
git:5.10.1
git-client:6.6.0
github:1.46.0
github-api:1.330-492.v3941a_032db_2a_
github-branch-source:1967.vdea_d580c1a_b_a_
gson-api:2.13.2-173.va_a_092315913c
handy-uri-templates-2-api:2.1.8-38.vcea_5d521d5f3
hidden-parameter:504.v610a_b_b_c05003
htmlpublisher:427
http_request:1.25
instance-identity:203.v15e81a_1b_7a_38
ionicons-api:94.vcc3065403257
jackson2-api:2.21.2-433.v6d50b_92cfe52
jackson3-api:3.1.1-68.v2a_4b_025ea_657
jakarta-activation-api:2.1.4-1
jakarta-mail-api:2.1.5-1
jakarta-xml-bind-api:4.0.6-12.vb_1833c1231d3
javax-activation-api:1.2.0-8
jaxb:2.3.9-143.v5979df3304e6
jenkins-design-language:1.27.25
jersey2-api:2.48-180.ve47b_264f849b_
jira:3.21
jjwt-api:0.11.5-120.v0268cf544b_89
job-dsl:3654.vdf58f53e2d15
joda-time-api:2.14.1-187.vdf2def02b_8a_1
jquery3-api:3.7.1-619.vdb_10e002501a_
jsch:0.2.16-95.v3eecb_55fa_b_78
json-api:20251224-185.v0cc18490c62c
json-path-api:3.0.0-218.vcd4dd1355de2
jsoup:1.22.1-76.v9cdb_2456c0e3
junit:1403.vd9d1413fd205
lockable-resources:1493.v0db_447235039
mailer:534.v1b_36f5864073
matrix-auth:3.2.9
matrix-project:870.v9db_fcfc2f45b_
mina-sshd-api-common:2.16.0-167.va_269f38cc024
mina-sshd-api-core:2.16.0-167.va_269f38cc024
netty-api:4.1.130.Final-24.ve7c35ce81a_b_d
okhttp-api:5.3.2-200.vedb_720a_cf1f8
opentelemetry:3.1589.ve81b_b_fa_927d5
opentelemetry-api:1.54.1.102.v276c93ee966d
parameter-separator:334.v1fc0e534c71d
parameterized-scheduler:379.v95c73f233a_df
performance:1014.va_b_80b_a_7e886f
pipeline-build-step:584.vdb_a_2cc3a_d07a_
pipeline-graph-analysis:254.v0f63a_a_447dca_
pipeline-groovy-lib:787.ve2fef0efdca_6
pipeline-input-step:551.vdff487c5998c
pipeline-milestone-step:152.v6e22b_8cfc66c
pipeline-model-api:2.2277.v00573e73ddf1
pipeline-model-definition:2.2277.v00573e73ddf1
pipeline-model-extensions:2.2277.v00573e73ddf1
pipeline-stage-step:345.va_96187909426
pipeline-stage-tags-metadata:2.2277.v00573e73ddf1
pipeline-utility-steps:2.20.0
plain-credentials:199.v9f8e1f741799
plugin-util-api:6.1192.v30fe6e2837ff
prism-api:1.30.0-703.v116fb_3b_5b_b_a_a_
pubsub-light:1.19
resource-disposer:0.25
scm-api:728.vc30dcf7a_0df5
script-security:1399.ve6a_66547f6e1
snakeyaml-api:2.5-149.v72471e9c6371
snakeyaml-engine-api:3.0.1-5.vd98ea_ff3b_92e
sonar:2.18.2
sse-gateway:1.29
ssh-credentials:372.va_250881b_08cd
sshd:3.384.vc89b_5e138cf9
structs:362.va_b_695ef4fdf9
timestamper:1.30
token-macro:477.vd4f0dc3cb_cf1
trilead-api:2.284.v1974ea_324382
variant:70.va_d9f17f859e0
woodstox-core-api:7.1.1-1.v4d297985f397
workflow-aggregator:608.v67378e9d3db_1
workflow-api:1413.v2ff1a_5e720fa_
workflow-basic-steps:1098.v808b_fd7f8cf4
workflow-cps:4238.va_6fb_65c1f699
workflow-durable-task-step:1475.ved562f6ec8b_3
workflow-job:1571.vb_423c255d6d9
workflow-multibranch:821.vc3b_4ea_780798
workflow-scm-step:466.va_d69e602552b_
workflow-step-api:724.v538c2362b_dfb_
workflow-support:1015.v785e5a_b_b_8b_22
ws-cleanup:0.49
What Operating System are you using (both controller, and any agents involved in the problem)?
Ubuntu 22.04
Reproduction steps
- Configure a Cloud in Jenkins with templates where the cloud max is greater than the pool
- Queue more jobs than the minimum pool
- Agents do not spin down after jobs complete.
Expected Results
When Dynamic buffer is disabled, the expectation would be that a buffer of 0 would be maintained, meaning in a state where no jobs are running or queued the amount of agents would be equal to the minimum pool size.
Actual Results
When dynamic buffer is disabled, the effective max VM limit seems to be set at either template or cloud max. This results in VMs not really scaling back, seemingly until they hit their retention time. I have not tested or investigated thoroughly on if this issue is also present when dynamic buffer is enabled.
Anything else?
Hello! Apologies if bug isn't the right category for this issue.
Recent changes seem to have caused a drift in past, documented, and functional behavior in my experience. PR #735 and #748 seem to be the ones introducing the new features.
I'm opening this issue to start the conversation around the desired direction prior to submitting a PR.
Past Behavior:
With the pooled retention strategy, a static minimum number of agents were provisioned. These agents were permitted to scale up when jobs were queued, and then agents were destroyed back down to the minimum size.
Recent Changes:
Recent changes seem to move to a model of having idle agents ready with the "Dynamic Buffer" feature, and wording of the documentation of settings don't mention scaling when the Dynamic Buffer, but does still allow a maximum. Essentially maintaining a pool somewhere between minimum and maximum, when the description for pool size communicates "Pool size define the number of agent you want to maintain." This is the discrepancy between documentation and actual behavior.
The Question:
Do we fix this deviation by updating the code and actual behavior, or updating the documentation to align with the new behavior of a pool size between the minimum and maximum being acceptable even when Dynamic Buffer is disabled?
Are you interested in contributing a fix?
Yes I am. Just would like to confirm the direction before proceeding with a PR.
Jenkins and plugins versions report
What Operating System are you using (both controller, and any agents involved in the problem)?
Ubuntu 22.04
Reproduction steps
Expected Results
When Dynamic buffer is disabled, the expectation would be that a buffer of 0 would be maintained, meaning in a state where no jobs are running or queued the amount of agents would be equal to the minimum pool size.
Actual Results
When dynamic buffer is disabled, the effective max VM limit seems to be set at either template or cloud max. This results in VMs not really scaling back, seemingly until they hit their retention time. I have not tested or investigated thoroughly on if this issue is also present when dynamic buffer is enabled.
Anything else?
Hello! Apologies if bug isn't the right category for this issue.
Recent changes seem to have caused a drift in past, documented, and functional behavior in my experience. PR #735 and #748 seem to be the ones introducing the new features.
I'm opening this issue to start the conversation around the desired direction prior to submitting a PR.
Past Behavior:
With the pooled retention strategy, a static minimum number of agents were provisioned. These agents were permitted to scale up when jobs were queued, and then agents were destroyed back down to the minimum size.
Recent Changes:
Recent changes seem to move to a model of having idle agents ready with the "Dynamic Buffer" feature, and wording of the documentation of settings don't mention scaling when the Dynamic Buffer, but does still allow a maximum. Essentially maintaining a pool somewhere between minimum and maximum, when the description for pool size communicates "Pool size define the number of agent you want to maintain." This is the discrepancy between documentation and actual behavior.
The Question:
Do we fix this deviation by updating the code and actual behavior, or updating the documentation to align with the new behavior of a pool size between the minimum and maximum being acceptable even when Dynamic Buffer is disabled?
Are you interested in contributing a fix?
Yes I am. Just would like to confirm the direction before proceeding with a PR.