action #157657
openPackageHub module activation while using SCC-proxy
0%
Description
Problem statement:¶
When registering the system using ProxySCC, activating the PackageHub module returns repos in OSD that don't exist.
This is expected, because the proxySCC replaces the repo URLs given by the real SCC by local openQA asset URL.
Normally, we use the proxySCC in the openQA jobs with SCC_URL variable, this will be used by the code to make the SUSEConnect call like this:
SUSEConnect -r $REGCODE --url http://all-67.1.proxy.scc.suse.de
This will make that all the repos returned look like this:
http://openqa.suse.de/assets/repo/...
And enabling any module, will have the same effect, for example PackageHub:
susetest:~ # suseconnect -p PackageHub/15.6/x86_64
Registering system to registration proxy http://all-67.1.proxy.scc.suse.de
Updating system details on http://all-67.1.proxy.scc.suse.de ...
Activating PackageHub 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Successfully registered system
And the repo will point to the wrong place:
18 | SUSE_Package_Hub_15_SP6_x86_64:SLE-Module-Packagehub-Subpackages15-SP6-Pool | SLE-Module-Packagehub-Subpackages15-SP6-Pool | Yes | (r ) Yes | No | http://openqa.suse.de/assets/repo/SLE-15-SP6-Module-Packagehub-Subpackages-POOL-x86_64-Build67.1-Media1/
Solution¶
To cope with this, we would need to sync the PackageHub module for EVERY build we have for 15-SP6. Another solution would be to tweak ProxySCC code to return the real URL instead of local assets.
BUT there is an easier way:
1) Register the system using the usual proxySCC
susetest:~ # SUSEConnect -r $REGCODE --url http://all-67.1.proxy.scc.suse.de
Registering system to registration proxy http://all-67.1.proxy.scc.suse.de
Announcing system to http://all-67.1.proxy.scc.suse.de ...
Activating SLES 15.6 x86_64 ...
-> Adding service to system ...
Activating sle-module-basesystem 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Activating sle-module-server-applications 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Activating sle-module-python3 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Successfully registered system
2) Activate the desired module using --url pointing to real SCC:
susetest:~ # SUSEConnect -p PackageHub/15.6/x86_64 --url https://scc.suse.com
Registering system to SUSE Customer Center
Updating system details on https://scc.suse.com ...
Activating PackageHub 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Successfully registered system
3) And voilá, you will get the repos from REAL SCC:
susetest:~ # zypper lr -u |grep -i PackageHub-15-SP6-Pool
22 | SUSE_Package_Hub_15_SP6_x86_64:SUSE-PackageHub-15-SP6-Pool | SUSE-PackageHub-15-SP6-Pool | Yes | (r ) Yes | No | https://updates.suse.com/SUSE/Backports/SLE-15-SP6_x86_64/product?RMMzfgZAuv8Hy903n30FsW6hbWs5KExVGGIwF1w5nRMdkliFvRBscHmgomWpHwFbG8l2C7cmrcZead-ejTo_f0NKbts7ZNwGBw0WtMwuWeKXxK2mgknqmbcYZ22y3RB3rThU1AMZTw
Updated by jlausuch about 1 year ago
In SLE Micro, we could also do the following. Instead of
SCC_URL=http://all-%BUILD%.proxy.scc.suse.de
we used
SCC_URL=http://micro-%BUILD%.proxy.scc.suse.de
This was making that only the main module (base product) was given the local assets as repos, but the other available modules (which didn't depend on the current build, like PackageHub and LivePatching) were activated with the real repos URLs.
This is because how proxySCC is designed. See
https://github.com/SUSE/scc-qa-proxy/blob/master/spec/suse/qa_proxy/response_spec.rb#L117
Maybe we could do something similar for SLES... telling it that packagehub activation should not replace the repos...
Updated by slo-gin 12 days ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.