OSD deployment fails presumably when handling the changelog
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/-/merge_requests/50 should've fixed it but it apparently didn't help.
- Due date set to 2022-12-02
- Status changed from New to Feedback
- Assignee set to okurz
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.
- Assignee deleted (
- Target version deleted (
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.
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.
- Due date deleted (
- Status changed from In Progress to Resolved