action #128927
closedOSD deployment changelog repeatedly mentions old os-autoinst changes, is a worker outdated and unable to install newer packages? size:M
0%
Description
Observation¶
Recent example from 2023-05-08:
You can find the details on https://gitlab.suse.de/openqa/osd-deployment/-/jobs/1558014
As always, if you encounter problems, please file tickets on https://progress.opensuse.org.
Have fun, your QA tools team
* Sun May 07 2023 okurz@suse.com
- Update to version 4.6.1683294886.8a7e554:
*
os-autoinst changes:
* Sun May 07 2023 okurz@suse.com
- Update to version 4.6.1683277334.0688448:
* Enable VNC endian conversion when worker is big-endian
* Add support for serial device of s390x in testapi
* dist: Fix unresolved dependency on chattr in OBS
* Show initialization errors of `isotovideo` again
* Test sending forced VNC update request explicitly
* container: Distinguish jq and non-jq variants in BuildTag
* Drop setting of TESSDATA_PREFIX in invoke-tests
* Replace Perl::Critic::{Freenode,Community}
* Add workaround to prevent `t/29-backend-generalhw.t` being unstable
* Cover all code of `console.pm`
* Fix CMake warning about ordering
* ci: Improve marking uncoverable statements
* Drop Leap-15.3 from OBS CI
I have seen the oldest os-autoinst changes mentioned here in before, e.g. "Drop Leap-15.3 from OBS CI". I assume we have the same problem that we had already in the past where at least one worker was unable to update packages due to ppc64le builds failing on devel:openQA
Acceptance criteria¶
- AC1: The problematic worker instance is receiving updates again with the same frequency as other workers
Suggestions¶
- Look into devel:openQA for build failures and fix them
- DONE Find the old ticket about "changelog" -> #124658
- Look into the deployment pipeline details
- Check that all salt machines are up-to-date or fix the found problem(s)
Updated by okurz over 1 year ago
- Related to action #120372: OSD deployment fails presumably when handling the changelog added
Updated by okurz over 1 year ago
- Related to action #124658: [osd-deployment] missing os-autoinst changes in deployment and changelog emails , build failure on ppc64le in OBS size:M added
Updated by mkittler over 1 year ago
- Subject changed from OSD deployment changelog repeatedly mentions old os-autoinst changes, is a worker outdated and unable to install newer packages? to OSD deployment changelog repeatedly mentions old os-autoinst changes, is a worker outdated and unable to install newer packages? size:M
- Description updated (diff)
- Status changed from New to Workable
Updated by mkittler over 1 year ago
The worker that was used to compute the changelog was QA-Power8-4-kvm. The worker looks generally good, e.g. zypper dup --allow-vendor-change
worked without any conflicts to resolve. I also don't see any PowerPC build failures at the moment.
salt -C 'G@roles:worker' cmd.run 'rpm -q os-autoinst'
shows that all workers are on the same os-autoinst version. The same counts for the openQA-worker
packages except that they are now a little bit ahead on the PowerPC workers as I've invoked zypper dup
there for testing purposes.
The worker openqaworker1.qe.nue2.suse.org
has also a newer openQA-worker
package. I'll have a look why that is.
Maybe we should always pick an x86_64 worker to generate the changelog for better consistency?
Updated by mkittler over 1 year ago
On openqaworker1.qe.nue2.suse.org
there was still openqa-auto-update.timer
and openqa-continuous-update.timer
running (in contrast to other OSD workers). For consistency, I disabled/stopped those services.
Updated by mkittler over 1 year ago
- Status changed from Workable to Feedback
Maybe we should always pick an x86_64 worker to generate the changelog for better consistenc
I think it would be beneficial so I went ahead and created https://gitlab.suse.de/openqa/osd-deployment/-/merge_requests/53.
Updated by mkittler over 1 year ago
- Status changed from Feedback to Resolved
Some time has passed so I ran the salt commands mentioned in my comment from last week again. Now everything is on the same version. The MR has been merged as well. So I suppose the issue can be considered resolved.