openEuler support

[juliogonzalez]

Target is supporting 20.03 LTS.

Research

• [x] Install the OS on a VM (try SP1 to see how service pack migration works)
• [x] Verify differences against CentOS8.
  • Installation seems to be the same as CentOS8, but rebranded. Offers only English as Chinese as languages.
  • Ships dnf, so it seems to be based on CentOS8, but does NOT provide modules (dnf module list --all does not show anything)
  • No Appstream, seems the equivalent is called Everything. But there is OS
  • It has a repo called EPOL. My guess is that it's the equivalent of EPEL
  • Has an /etc/openEuler-release file, and /etc/os-release contains:

  NAME="openEuler"
  VERSION="20.03 (LTS-SP1)"
  ID="openEuler"
  VERSION_ID="20.03"
  PRETTY_NAME="openEuler 20.03 (LTS-SP1)"
  ANSI_COLOR="0;31"
  

  • Other than this seems to be a pretty standard CentOS8 clone, but most likely with different packages and versions for those that CentOS8 ships. Maybe the equivalent would be (to some extent) what Amazon Linux 2 is to CentOS7.
  • Interesting fact: they use OBS (https://build.openeuler.org/)
• [ ] Research release cycle

Implementation

• [ ] Support at our salt package. On paper upstream show support openEuler as I found https://github.com/saltstack/salt/pull/58973 (my guess, is that openEuler still identifies itself as family RedHat, because I don't see anything specific at https://github.com/juliogonzalez/salt/blob/develop/salt/grains/core.py, so maybe I just need to backport https://github.com/saltstack/salt/pull/58973)
• [ ] PR for spacewalk-common-channels, susemanager-sls, and spacewalk-cert-tools. Base: https://github.com/uyuni-project/uyuni/pull/3681
• [ ] Verify if our EL8 client tools can work with openEuler 20.03, or if we need a new set of client tools.
• [ ] PR for spacewalk-java and susemanager-schema: https://github.com/uyuni-project/uyuni/pull/3959

[juliogonzalez]

First thing needed:

[root@m224 yum.repos.d]# dnf install salt-minion
Failed to set locale, defaulting to C.UTF-8
Last metadata expiration check: 0:00:20 ago on Sat Jul 24 01:02:51 2021.
Error: 
 Problem: conflicting requests
  - nothing provides /usr/libexec/platform-python needed by salt-minion-3002.2-25.1.uyuni.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

It seems that not only openEuler does not have modules, but it doesn't have /usr/libexec/platform-python either. Python 3.7 is installed by defect, however.

That means we'll need to use some macro at the salt SPEC to check if we are on openEuler and not on RHEL8 and clones.

According to https://github.com/openeuler-mirror/openEuler-rpm-config/blob/master/macros, the right macro is %{_vendor}, but I can't find any macro that specifies the version, if we ever need it.

Let's try at https://build.opensuse.org/project/show/home:juliogonzalezgil:branches:systemsmanagement:Uyuni:Master:EL8-Uyuni-Client-Tools

[juliogonzalez]

[root@m224 ~]# rpm --eval '%{openEuler}'
2

[juliogonzalez]

https://build.opensuse.org/project/show/openEuler:20.03 and https://build.opensuse.org/project/show/openEuler:21.03 do not have "Everything"; that contain the packages we need to build salt (that CentOS does not have, but openEuler has).

I requested then at the build service list.

That's it for today :-)

[juliogonzalez]

Everyuthing requested at https://progress.opensuse.org/issues/96473 (as well as at the buildservice list)

[juliogonzalez]

Part of Hackweek 21 at https://hackweek.opensuse.org/21/projects/testing-gnu-slash-linux-distributions-on-uyuni

[raulillo82]

Update for Hackweek 21:

Target is supporting 22.03 LTS.

Research

• [x] Install the OS on a VM.
• [x] Verify differences against CentOS8:
• Installation seems to be the same as CentOS8, but rebranded. Offers only English as Chinese as languages.
• Ships dnf, so it seems to be based on CentOS8, but does NOT provide modules (dnf module list --all does not show anything)
• No Appstream, seems the equivalent is called Everything. But there is OS
• It has a repo called EPOL. My guess is that it's the equivalent of EPEL
• Has an /etc/openEuler-release file, and /etc/os-release contains:

NAME="openEuler"
VERSION="22.03 LTS"
ID="openEuler"
VERSION_ID="22.03"
PRETTY_NAME="openEuler 22.03 LTS"
ANSI_COLOR="0;31"

• Other than this seems to be a pretty standard CentOS8 clone, but most likely with different packages and versions for those that CentOS8 ships. Maybe the equivalent would be (to some extent) what Amazon Linux 2 is to CentOS7.
• Interesting fact: they use OBS (https://build.openeuler.org/)
• [ ] Research release cycle See: https://github.com/openeuler-mirror/release-management/blob/master/lifecycle.md Apparently, SPs released in June and December, 3 of them (so the first SP is released only 3 months after GA shipment). SP3 (almost?) happens at the same time than the next LTS release GA shippment.

[raulillo82]

[root@openeuler ~]# dnf install salt-minion
Last metadata expiration check: 0:52:07 ago on Mon 27 Jun 2022 12:39:16 PM CEST.
Error: 
 Problem: cannot install the best candidate for the job
  - nothing provides python(abi) = 3.6 needed by salt-minion-3004-16.2.uyuni.x86_64
  - nothing provides /usr/libexec/platform-python needed by salt-minion-3004-16.2.uyuni.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@openeuler ~]# python3 --version
Python 3.9.9
[root@openeuler ~]# rpm --eval '%{openEuler}'
2

[raulillo82]

Requested to have openEuler 22.03 added into OBS through Slack (will be mostly a clone of 20.03 meta file omitting the SP and changing the version to 22.03).

[raulillo82]

Comparing whether SPs are really that different or basically the same. For that purpose, GA, SP2 and SP3 were installed for the previous version, 20.03. For SP2 and SP3, the netiso was used. It was needed to add the installation repo manually in the installer (https://repo.openeuler.org/openEuler-20.03-LTS-SP3/OS/x86_64/ and the same with SP2 for SP2). For GA, doing the installation with the full iso (4GB, as no netiso existed), even providing a repo source for the installation in the installer added no repositories by default to the system. That being said, some comparison between SPs:

(GA vs SP2 vs SP3)

• Python versions: 2.7.16 & 3.7.4 vs 2.7.18 & 3.7.9 vs 2.7.18 & 3.7.9
• Glibc versions: glibc-2.28-84.oe1.x86_64 vs glibc-2.28-36.oe1.x86_64 vs glibc-2.28-69.oe1.x86_64
• Kernel: 4.19.90-2003.4.0.0036.oe1.x86_64 vs 4.19.90-2106.3.0.0095.oe1.x86_64 vs 4.19.90-2112.8.0.0131.oe1.x86_64

Default repos in SP2 vs SP3: OS, everything, EPOL, EPOL-UPDATE, debuginfo, source, update. EPOL-UPDATE was missing in SP3, but probably simply a bug because it existed. GA didn't provide any repos. Maybe because of having used the full iso (even having provided an online repo during installation time).

[juliogonzalez]

Release cycle:

It's clear the SPs are considered different "products", somehow similar to SLE, but with more frequent releases.

For now, let's focus on see if we can support 22.03, and we'll see later what to do about SPs, if there's enough community interest.

[raulillo82]

Update for HackWeek 22: The salt bundle PoC used in the previous HackWeek was broken (I noticed a rebuild in December, which might be related). I've opened an issue against salt, see: https://github.com/openSUSE/salt/issues/577 So everything will need to be retested once fix. I could at least make sure that the repos sync properly, without errors in the erratas this time (there was an old issue for that that was fixed).

[raulillo82]

Previous issue is solved. Next steps:

• [ ] Adapt the url's for the Uyuni client tools: https://github.com/uyuni-project/uyuni/issues/7642
• [ ] Fix error with wrong file in /usr/share/susemanager/salt/certs/openeuler.sls (should be a copy, and not a link, of redhat.sls): https://github.com/uyuni-project/uyuni/issues/7635