import ELN (HMS-10620, HMS-10621, HMS-10623)#2318
Conversation
supakeen
force-pushed
the
import-eln
branch
2 times, most recently
from
12592b9 to
3461168
Compare
|
RPM repo snapshots already existed. I've updated the commit to use them. |
supakeen
force-pushed
the
import-eln
branch
8 times, most recently
from
c20feb4 to
a4df927
Compare
supakeen
changed the title
|
Undrafted; this is a pretty rough gem at the moment but getting it in gives us a good opportunity to iterate on this. I have a local branch that does a bunch of deduplication in the installers and disk images (but also changes them) which I'm leaving out of this PR but will come after. |
|
CI was failing on the installer images. The |
supakeen
force-pushed
the
import-eln
branch
2 times, most recently
from
a5607e5 to
b8f2580
Compare
|
With the newer Seems that todays compose has the broken things untagged so I'm going to do a new rpmrepo snapshot. |
|
With the latest snapshot it seems Azure is the only thing to not boot; I'll take a look tomorrow. |
|
Going to temporarily pause this PR until ELN kernels get into less choppy waters. |
|
Validate manifest checksums here is a false positive (?); it's pointing at the CI-change commit but no manifests changed there. |
Would maybe having |
Rename the `_common.yaml` file to `_shared.yaml` and introduce a `_shared` section. This allows the `.common` section to still be used in separate `imagetype.yaml`'s. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Since we have the ability to have a `_shared.yaml` that needs to be prepended to form a full YAML file I'll have to adjust our yaml linting test. We now go over all directories; if they contain YAML files *and* a `_shared.yaml` then concatenate them otherwise just test the YAML file itself. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Allow for a distro-like of ELN. I've opted for an entirely separate one here so it can later be cloned onto a potential EL-11. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
This is a straight import of the RHEL-10 definitions but split out to use the recently introduced idiom of having a `_shared.yaml` and the ability to have multiple YAML files containing image types. This gives us slightly nicer organisation. Also define repositories for the distribution and regenerate CI configuration. Next commits iterate on the definitions to make things nicer but this initial import generates the checksums so that follow-ups show which manifests change. A few things are directly addressed here as I've encountered them; so we can produce the initial checksums: - Drop use of `platform-python` in the ELN-11 buildroot. - Use new names for IWL firmware packages. - `dnf-plugins-core` instead of `(dnf|yum)-utils`. There's also a few things I've temporarily disabled: - Replace `dnf-plugins-core` with `dnf5-plugins`. - Comment out `ftp`. It's not available in ELN at the moment but might be reinstated? - Comment out `redhat-release-eula`; this one is interesting and we might re-enable it when provided by `fedora-eln-release`? - Comment out `google-cloud`-related packages; they are not available at the moment. - Comment out the `timedatex` package; it is not available at the moment. - Stop excluding `openldap` in containers; it makes dependency resolution break as other things now depend on it. - Stop excluding some other libraries in containers as well; same issue as above. We might reintroduce exclusions again after we figure everything out. - Remove dataloss script; it might be reintroduced but it's currently failing (Azure's VHD) And I've adjusted to the new cloud-init service names. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
RHEL conditions don't apply on ELN so we can safely remove them. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
|
I've rebased and undrafted; this is a good starting point to start iterating in followups and CI is about to go green. |
thozza
left a comment
thozza
left a comment
There was a problem hiding this comment.
In general, LGTM, but I have one comment....
| conditions: | ||
| "add insights pkgs on rhel": | ||
| when: | ||
| distro_name: "rhel" | ||
| append: | ||
| include: | ||
| - "insights-client" | ||
| - "subscription-manager-cockpit" |
There was a problem hiding this comment.
One can argue that condition like this one will be later missed when we fork el11/c11s from eln... It may be a good idea to keep those here or add them to the base package set, to prevent us from missing this addition later.
There was a problem hiding this comment.
I'm not entirely sure about this either; we can do either. I felt it to be OK to re-add them when we import but let's see what others think in this case since I'm pretty neutral as well.
3 participants
Introduction of a new distribution separate from Fedora and RHEL-alikes called 'ELN' (Enterprise Linux Next). Initially created from a copy of the RHEL-10 definitions.
ELN is to be the next RHEL. We have a major version of 11 set on it even if it is meant to behave like a stream. When CentOS Stream 11 forks off of ELN we will copy over the ELN-11 definitions to RHEL-11; drop ELN-11 and introduce ELN-12 (using the same repositories); the process will then repeat for RHEL-12, etc.
We'll be handling the stream-bits by allowing the omission of the major version in
image-builder's--distroargument (e.g.image-builder build --distro eln ...).Any changes to image types we wish to make in RHEL-11 can be done in ELN-11 and it also lets us find unavailable packages and other changes earlier. This initial import does very little of the sort.
I have used the new 'split imagetypes' introduced by @avitova to organize things a bit better but more can be done.
The intent is to (eventually) build these images in Fedora's infrastructure with
image-builderso ELN images that have RHEL counterparts are built the same way as RHEL and CentOS do.Related GitHub issues: