action #120372
OSD deployment fails presumably when handling the changelog
0%
Description
Observation¶
The deployment fails with:
++ ssh openqa.suse.de 'set -xo pipefail; sudo salt -C '\''worker2*'\'' cmd.run '\''rpm -q --changelog os-autoinst'\'' | sed '\''s/^ //'\'' > /tmp/os-autoinst-before_changelog && sudo salt -C '\''G@roles:worker'\'' cmd.run '\''rpm -qa | grep "\(os-autoinst\|openQA\)" > /tmp/osd-deployment_rpm_q'\''' + sudo salt -C 'worker2*' cmd.run 'rpm -q --changelog os-autoinst' + sed 's/^ //' .ERROR: No return received
(https://gitlab.suse.de/openqa/osd-deployment/-/jobs/1238261)
Further notes¶
- https://gitlab.suse.de/openqa/osd-deployment/-/merge_requests/50 should've fixed it but it apparently didn't help.
History
#3
Updated by cdywan 3 months ago
okurz wrote:
https://gitlab.suse.de/openqa/osd-deployment/-/merge_requests/51
I feel like we should rethink the purpose of this. Using a random worker to look rpm changelogs can't tell us if the deployment was consistent. We could equally get changelogs straight from OBS.
#4
Updated by mkittler 3 months ago
- Assignee deleted (
okurz) - Target version deleted (
Ready)
This isn't to validate whether the deployment was consistent. It is to obtain some changelogs for the mail (that are at least valid for a subset of workers). Note that OBS is not necessarily in sync with what we've deployed as well (e.g. a new package might have been built in the meantime). Besides, OBS doesn't know what our last installed version was so we still needed to track at least that.
#7
Updated by okurz 3 months ago
I introduced one problem that the $()
was executed prematurely in the CI environment instead of on the remote host. https://gitlab.suse.de/openqa/osd-deployment/-/commit/982c8f2c1b8cf177263526d2c11c5de2cecae5ea should fix that. https://gitlab.suse.de/openqa/osd-deployment/-/jobs/1240298 confirmed.