fix: use throttle: 1 for localhost unarchive #498
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
travisdowns
force-pushed
the
td-fix-457
branch
from
6582161 to
f140430
Compare
travisdowns
changed the title
github-actions
bot
added
bugfix
roles/_common
roles/alertmanager
roles/bind_exporter
roles/blackbox_exporter
roles/cadvisor
roles/chrony_exporter
roles/fail2ban_exporter
roles/gitlab_ci_pipelines_exporter
roles/influxdb_exporter
roles/ipmi_exporter
roles/memcached_exporter
roles/mongodb_exporter
roles/mysqld_exporter
roles/nginx_exporter
roles/node_exporter
roles/nvidia_gpu_exporter
roles/postgres_exporter
roles/process_exporter
roles/prometheus
roles/pushgateway
roles/redis_exporter
roles/smartctl_exporter
roles/smokeping_prober
roles/snmp_exporter
roles/systemd_exporter
labels
travisdowns
force-pushed
the
td-fix-457
branch
from
f140430 to
d0e0f24
Compare
|
I tested this locally with a file that is more likely to trigger the race: a tar of 10,000 small files all at the top level of the tar: this triggers the error 100% of the time w/o the fix and passes 1,000 iterations locally with no failures. I also verified that deploying prom to a 4 host inventory works, 100 iterations without failure. This inventory has 2 hosts each for 2 different architectures (amd64 and arm64). |
gardar
approved these changes
Jan 6, 2025
SuperQ
reviewed
Jan 6, 2025
During the common install tasks, we download and unpack the binary to install on localhost and eventually upload it to each host (among many other things). Currently the "unpack" step, which extracts the gzipped tar archive, is perform N times if there are N hosts in the inventory, but the target directory (something like /tmp/node_exporter-linux-arm64/1.8.2) is the same for every host with the same architecture. This means that all the unarchive tasks are extracting in parallel in an unsynchronized manner to the same directory. It a miracle that this works, but at least usually it like it does, but sometimes tar will complain about a missing file, failing the install. I've confirmed locally that this is due to the race described above. To fix this, we use `throttle: 1` on the unpack task. This means that the first task (for each architecture) will do the unpack and the other tasks are effectively no-ops, they are reported as "ok" rather than changed in the output. Fixes prometheus-community#457. Co-authored-by: Ben Kochie <[email protected]> Signed-off-by: Travis Downs <[email protected]>
travisdowns
force-pushed
the
td-fix-457
branch
from
8079f7f to
be70705
Compare
|
The test failures look like this: I believe this means the external resource has changed. It looks like the user changed their name and the correct link is: |
|
I think the 308 error is related to #507 |
|
Please rebase now that the 308 error should be resolved |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
During the common install tasks, we download and unpack the binary to install on localhost and eventually upload it to each host (among many other things). Currently the "unpack" step, which extracts the gzipped tar archive, is perform N times if there are N hosts in the inventory, but the target directory (something like
/tmp/node_exporter-linux-arm64/1.8.2) is the same for every host with the same architecture.
This means that all the unarchive tasks are extracting in parallel in an unsynchronized manner to the same directory. It a miracle that this works, but at least usually it like it does, but sometimes tar will complain about a missing file, failing the install. I've confirmed locally that this is due to the race described above.
To fix this, we use
throttle: 1on the unpack task. This means that the first task (for each architecture) will do the unpack and the other tasks are effectively no-ops, they are reported as "ok" rather than changed in the output.Fixes #457.