| commit | 7896160ac2060aca667e9c68ac69f450b7dba144 | [log] [tgz] |
|---|---|---|
| author | Paul Sokolovsky <paul.sokolovsky@linaro.org> | Tue Apr 04 23:52:46 2023 +0300 |
| committer | Paul Sokolovsky <paul.sokolovsky@linaro.org> | Tue Apr 04 23:52:46 2023 +0300 |
| tree | 783b00f74fd50a56df051ef7e8bb12a4b7ebe755 | |
| parent | 864c22c44870e24bb525ebb67e7335938eded209 [diff] |
hosts: Set max_containers at 50 Myself (and other folks) applied this workaround directly in Jenkins GUI for a while (a year or so). But recently, due to an issue (STG-4396) we actually can't apply it via GUI, so have little choice but to encode it here. The motiviation and idea behind this workaround is following: x86_64-TF-02 is shared by both production and staging. And bother have max_containers for it at 30. But that means that if production is running full-steam (and most of the time it is, that's the purpose of production - to run a lot of stuff almost all the time), then there's simply no room for staging to run any container (it sees 30 running from production already). But staging is used for development work and thus should have "interactive priority" for its job (them to be able to start quickly, but the jobs themselves should be "lightweight"). To achieve that aim, there's little choice but to set staging's max_containers *higher* than production. For example, at 50, staging would be able to run 50 - 30 = 20 containers even if production is fully booked. Of course, such usage exactly depends on the idea that the staging would run "interactive priority" jobs, for narrow-focused development and testing. If that rule is not followed, we may get "priority inversion", where staging will suffocate production with its 50 concurrently running jobs. During the time the workaround was applied manually, there was suitable motion to establish staging usage discipline, and it's under constant watch, so should be ok to promote manual workaround to persistent workaround. Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org> Change-Id: Ifb93e3caa64f72b94584b1c61a8b71d050a34dce
Yet Another Docker Plugin (YADP) is extremely hard to manage, when running multiple slaves with multiple images. Due to the way Jenkins displays the configuration page. YADP provides a groovy script which builds a JSON array to populate the configuration in Jenkins.
This script uses YAML and Jinja2 to generate a java JSONARRAY to build the configuration, using a !include constructor in the YAML file, allowing the ability to template up docker_images, since many of our slaves run the same image, it lessens repetition.
####hosts
- host1:
cloud_name: host1.example.org
docker-url: tcp://0.0.0.0:2375
docker_templates: !include external_template_file.yml
- host2:
cloud_name: host2.example.org
docker-url: tcp://0.0.0.1:2375
docker_templates:
- xenial-amd64:
docker_image_name: 'ubuntu:latest'
max_instances: '1'
labels: 'docker-ubuntu'
launch_method: ssh
ssh:
launch_ssh_credentials_id: 'random-id'
launch_ssh_port: '22'
- host3
cloud_name: host3.example.org
docker-url: tcp://0.0.0.0:2375
docker_templates:
!include [external_template_file.yml, external_template_file_2.yml]
Due to the nature of YAML and populating the Java JSONARRAY, its important that YAML is phased correctly.
Most of the limitations surround docker_templates.
A list of limitations and pending improvements.
Example of broken approach:
Example of broken approach: