Bug 1214634

Summary: [HPS Bug] HPE requires abillity to mirror Dolomite repos internally
Product: [openSUSE] PUBLIC SUSE Linux Enterprise Micro 6.0 Reporter: Randy Wright <rwright>
Component: BaseAssignee: Prokop Vlasin <prokop.vlasin>
Status: RESOLVED FIXED QA Contact: Jose Lausuch <jalausuch>
Severity: Critical    
Priority: P5 - None CC: andy.liang, asadeghpour, bryan.gartner, gail.cheng, jenifer.golmitz, jerry_hoemann, joe.liao, Karen.Skweres, poswald, scott.norton
Version: unspecified   
Target Milestone: ---   
Hardware: x86-64   
OS: SUSE Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Randy Wright 2023-08-25 17:21:51 UTC
Description of problem:
There are two problems occurring for HPE as a result of the content provided in the provided zypper repo file:
 
fingal01:~ # cat /etc/zypp/repos.d/ALP-Dolomite-1.0.repoetc/zypp/repos.d/ALP-Dolomite-1.0.repo
[ALP-Dolomite-1.0]
name=ALP Dolomite 1.0 Repository
enabled=1
autorefresh=1
baseurl=https://updates.suse.com/SUSE/Products/ALP-Dolomite/1.0/$basearch/product/

First, certain transactional-update command usages will proactively try to check for updates and because the lab firewalls block external access, will encounter long delays and subsequent error messages.  I will note that the majority of testers inside HPE are not instructed to use proxies to resolve issues like this:

fingal01:~ # unset NO_PROXY HTTPS_PROXY HTTP_PROXY
fingal01:~ # transactional-update grub.cfg
Checking for newer version.
     < long delay here >
Problem retrieving files from 'ALP Dolomite 1.0 Repository'.
Timeout exceeded when accessing 'https://updates.suse.com/SUSE/Products/ALP-Dolomite/1.0/x86_64/product/repodata/repomd.xml'.
Timeout reached Curl error (28)
Please see the above error message for a hint.
Some of the repositories have not been refreshed because of an error.
transactional-update 4.2.1 started
Options: grub.cfg
Separate /var detected.

The transactional-update command in this case eventually performs the requested update of grub.cfg.  However, the delay and the messaging that indicates an error will inevitably be reported as a bug by our testers.

The problem case above could be avoided by for example discarding the supplied
repo file /etc/zypp/repos.d/ALP-Dolomite-1.0.repo or using --no-selfupdate ... however that workaround does not provide a method to installed needed packages and/or install rpm packages that have dependencies. 

fingal01:~ # transactional-update --no-selfupdate pkg install /root/amsd-3.3.0-1773.7.sles15.x86_64.rpm 
transactional-update 4.2.1 started
Options: --no-selfupdate pkg install /root/amsd-3.3.0-1773.7.sles15.x86_64.rpm
Separate /var detected.
2023-08-25 11:17:21 tukit 4.2.1 started
2023-08-25 11:17:21 Options: -c9 open 
2023-08-25 11:17:22 Using snapshot 9 as base for new snapshot 10.
2023-08-25 11:17:22 Syncing /etc of previous snapshot 7 as base into new snapshot "/.snapshots/10/snapshot"
2023-08-25 11:17:22 SELinux is enabled.
ID: 10
2023-08-25 11:17:23 Transaction completed.
Calling zypper install
2023-08-25 11:17:26 tukit 4.2.1 started
2023-08-25 11:17:26 Options: callext 10 zypper -R {} install /root/amsd-3.3.0-1773.7.sles15.x86_64.rpm 
2023-08-25 11:17:27 Executing `zypper -R /tmp/transactional-update-f2QqDD install /root/amsd-3.3.0-1773.7.sles15.x86_64.rpm`:
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides 'libjson-c.so.3()(64bit)' needed by the to be installed amsd-3.3.0-1773.7.sles15.x86_64
 Solution 1: do not install amsd-3.3.0-1773.7.sles15.x86_64
 Solution 2: break amsd-3.3.0-1773.7.sles15.x86_64 by ignoring some of its dependencies

Version-Release number of selected component (if applicable):
Milestone 3

How reproducible:
Each time example transactional-update commands are used at HPE

Steps to Reproduce:
1. Delay and error message result from: transactional-update grub.cfg
2. Inability to install rpm packages with dependencies using transactional-update pkg install

Actual results:
As noted in problem description above

Expected results:
No such problems

Additional info:
In bug 1208390 I reported in essence this same issue, which was resolved:

| If your repos are non-functional, the correct solution for your problem is to
| disable the repos.

I accepted that for my own testing at the time, but the solution is really incomplete to meet goals such as dependency resolution when packages are installed.  I suggest the solution is that we need to mirror the pre-release repo by the same means we mirror for example the iso itself.
Comment 2 Cheng 2024-03-21 07:31:18 UTC
Any further update for the bug? Thank you.
Comment 3 Frederic Crozat 2024-03-21 10:34:28 UTC
All repositories are now properly available through SCC.

However, Dolomite as a product is cancelled. There was a communication to our partners earlier this week, which contains all the details.

I suggest to move your tests to SLE Micro 6.0, which was the base of Dolomite. And all repositories for SLE Micro 6.0 can be mirrored like other SLES15 repositories using RMT.
Comment 4 Ahmad Sadeghpour 2024-03-21 11:30:54 UTC
(In reply to Cheng from comment #2)
> Any further update for the bug? Thank you.

Please work with Jenifer and Randy for update
Comment 5 Cheng 2024-03-25 04:31:16 UTC
(In reply to Ahmad Sadeghpour from comment #4)
> (In reply to Cheng from comment #2)
> > Any further update for the bug? Thank you.
> 
> Please work with Jenifer and Randy for update

Even I could get updates from Jenifer and Randy, the SUSE bugzilla should reflect the status as well. At least, the bug status is not NEW after 6 months, right?Thanks to Frederic's latest update to change the NEW to RESOLVED.