action #128123: Handle vendor change issues in automation for migration cases that with PackageHub installed - qe-yam - openSUSE Project Management Tool

Custom queries

openQA Infrastructure Project
openqa-review - Closed tickets last updated by openqa-review, last 30 days
QA roadmap long-term
QA SLE functional
QA SLE Functional - closed in last 14 days
QA SLE Functional - High, need to be refined
QA SLE Functional - over cycle time median
QA SLE u
QA SLE y
QA tools (tag not necessary in openQA and subprojects)
QA tools tag (tag not necessary in openQA and subprojects; excluding tickets in "Ready" version as they are already on the backlog)
QAC - Backlog
QE tools team - backlog (dev)
QE tools team - backlog (ready issues)
QE tools team - backlog SLA high
QE tools team - backlog SLA immediate
QE tools team - backlog SLA no immediate/urgent in feedback/blocked
QE tools team - backlog SLA normal
QE tools team - backlog SLA urgent
QE tools team - backlog SLO high
QE tools team - backlog SLO normal
QE tools team - backlog SLO urgent
QE tools team - backlog, high-level view (epics and higher)
QE tools team - backlog, non-reactive work, needs parent
QE tools team - backlog, top-level view (all sagas)
QE tools team - closed within last 14 days
QE tools team - closed within last 60 days
QE tools team - closed yesterday
QE Tools Team - Collaborative Session
QE tools team - due date forecast
QE tools team - exceeding due-date
QE tools team - infrastructure backlog
QE tools team - next - sorted by update time
QE tools team - next issues
QE tools team - non-estimated (unblocked) issues (dev)
QE tools team - non-estimated (unblocked) issues (infra)
QE tools team - ready issues - Workable
QE tools team - ready, not assigned/blocked/low
QE tools team - SLO high forecast
QE tools team - update forecast
QE tools team - updated by priority
QE tools team - what members of the team are working on - Feedback (not-low)
QE Tools Team Backlog By Assignee
QE Yam backlog
QE Yam blocked issues
QE Yam closed yesterday
QE Yam issues IN_PROGRESS
QE Yam new action tickets per day
QE Yam new actions
QE Yam prio high, no updates last 4 weeks
QE Yam prio low & normal, no update for 1 year
QE Yam recjected yesterday
QE Yam resolved yesterday
QE Yam workable actions
soft failure tickets in progress
softfailure tickets resolved
softfailure tickets workable
Tools Team Retrospective
Tools Team Retrospective (not estimated or assigned)

Actions

Copy link

action #128123

closed

coordination #130072: [epic] Handle openQA adaptions in Yam squad - SLE 15 SP6

Handle vendor change issues in automation for migration cases that with PackageHub installed

Added by zoecao over 1 year ago. Updated over 1 year ago.

Status:

Resolved

Priority:

Normal

Assignee:

leli

Target version:

Current

Start date:

2023-04-21

Due date:

% Done:

Estimated time:

Description

Motivation:
It happens that if migration with PackageHub, some packages' vendor would change, the vendor of packages from SLE products repos is SUSE, and the vendor of packages from PackageHub repo is openSUSE. See the case:
http://openqa.suse.de/tests/10953226#step/resolve_dependency_issues/13

Need to handle the vendor change issue for this kind of warning. This might the way:
https://en.opensuse.org/SDB:Vendor_change_update#Full_repository_Vendor_change
like:
You can define a list of repositories having different "vendors" as equivalent by creating a file in the /etc/zypp/vendors.d/ directory with a similar content:

[main]

vendors = suse,opensuse,obs://build.suse.de,Packman,http://packman.links2linux.de

Adding BREAK_DEPS=1 to the case setting can also resolve it, but this setting may make us miss the real file conflict bugs.

Files

Download all files

yast2_ui_config_vendor_change_1.png (106 KB) yast2_ui_config_vendor_change_1.png		zoecao, 2023-05-23 08:13
yast2_ui_config_vendor_change_3.png (56.5 KB) yast2_ui_config_vendor_change_3.png		zoecao, 2023-05-23 08:14
yast2_ui_config_vendor_change_4.png (78.2 KB) yast2_ui_config_vendor_change_4.png		zoecao, 2023-05-23 08:16
yast2_ui_config_vendor_change_5.png (86.5 KB) yast2_ui_config_vendor_change_5.png		zoecao, 2023-05-23 08:19
yast2_ui_config_vendor_change_6.png (142 KB) yast2_ui_config_vendor_change_6.png		zoecao, 2023-05-23 08:22

History
Notes
Property changes

Actions

Copy link

Updated by openqa_review over 1 year ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: offline_sles15sp2_ltss_pscc_basesys-srv-phub_def_full
https://openqa.suse.de/tests/11022688#step/resolve_dependency_issues/1

To prevent further reminder comments one of the following options should be followed:

The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
The openQA job group is moved to "Released" or "EOL" (End-of-Life)
The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions

Copy link

Updated by shukui over 1 year ago

Same issue here: https://openqa.suse.de/tests/11051667

Actions

Copy link

Updated by zoecao over 1 year ago

File vendor_change_screenshot_1.png added
File vendor_change_screenshot_2.png added
File vendor_change_screenshot_3.png added

I have manually tested the workaround for handling vendor change based on this doc:
https://en.opensuse.org/SDB:Vendor_change_update#Full_repository_Vendor_change
Update the result here:

Using the yast2 UI, it works fine, steps as below:
1. During migration by yast, if see conflicts, screenshot as below
2. Click "Packages", the conflict will popup, check the content of the conflict, confirm it is about vendor change.
3. Click "Cancel" on the popup window to do workaround (may need to click several times, it depends on the number of packages that would change vendor)
4. Click "View" -> "Repositories" , choose the repo that you want to switch and click "Switch system packages" to the versions in this repository", (then the system will use the packages in this repo, evenif the other repos have a higher package version), see screenshot for this step PS: I suppose we need to switch to all the modules' update repo except "PackageHub" repos, because we don't which package would change vendor and which repo it come from.
5. After done with switch the repos, click "Accept" and then click "Continue" to accept the changes, screenshot: then the conflict warning about vendor change will disappear, the system can continue to do migration.

And I also tried the way of creating a file in the /etc/zypp/vendors.d/ directory with content:
[main]

vendors = suse,opensuse

it doesn't work, maybe because the content I wrote is incorrect, anyway, we could use the yast2 UI way.

Actions

Copy link

Updated by JERiveraMoya over 1 year ago

Target version deleted (~~Current~~)
Parent task set to #121876

Actions

Copy link Download all files

Updated by zoecao over 1 year ago

File yast2_ui_config_vendor_change_1.png yast2_ui_config_vendor_change_1.png added
File yast2_ui_config_vendor_change_3.png yast2_ui_config_vendor_change_3.png added
File yast2_ui_config_vendor_change_4.png yast2_ui_config_vendor_change_4.png added
File yast2_ui_config_vendor_change_5.png yast2_ui_config_vendor_change_5.png added
File yast2_ui_config_vendor_change_6.png yast2_ui_config_vendor_change_6.png added

I asked yast developers about how to allow vendor change in YaST UI, below is the steps:

During migration by yast, if see conflicts, click "Packages", see screenshot as below:
Then the conflicts will popup, need to cancel them one by one to go into the YaST Software. ==
Click the "Options" in the menu, and then click "yast2_ui_config_vendor_change_5.png":
Then click the "Accept" and click "Continue" (twice in my manually test, one for packages changes one for Packagehub product) for the changes:
It would go into the Installation Overview without the conflicts (of the vendor changes).