-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for modules #2760
Add support for modules #2760
Conversation
Skipping CI for Draft Pull Request. |
Testing this with: diff --git a/manifest.yaml b/manifest.yaml
index aaf361d..7b23804 100644
--- a/manifest.yaml
+++ b/manifest.yaml
@@ -14,6 +14,8 @@ repos:
# still pinned
- fedora
- fedora-updates
+ - fedora-modular
+ - fedora-updates-modular
# All Fedora CoreOS streams share the same pool for locked files.
# This will be in fedora-coreos.yaml in the future so it can be more easily be
diff --git a/manifests/fedora-coreos-base.yaml b/manifests/fedora-coreos-base.yaml
index 2dc6e9a..6065a1e 100644
--- a/manifests/fedora-coreos-base.yaml
+++ b/manifests/fedora-coreos-base.yaml
@@ -192,6 +192,9 @@ packages:
# https://github.com/coreos/fedora-coreos-tracker/issues/509
- zram-generator
+modules:
+ - cri-o:1.20
+
# This thing is crying out to be pulled into systemd, but that hasn't happened
# yet. Also we may want to add to rpm-ostree something like arch negation;
# basically right now it doesn't exist on s390x.
|
78fbdc6
to
3e7c820
Compare
Now with client-side support!
|
Requires: rpm-software-management/libdnf#1206 This is also still missing tests. (And oh yeah, lots of prep patches to split out!) |
One really important thing to understand in this IMO is that modules are entirely a repomd concept. Once the RPMs are on disk, there's nothing in the rpmdb for example to tell that you have module NSVCA/P installed. One consequence of this for example is that whenever we have to deal with modules, we always have to setup the sack to have libdnf parse the repomd. |
I always thought it was weird that yum/dnf/zypper etc. have distinct out of band databases from the rpm one. Perhaps now with the switch to sqlite that could be fixed? OTOH we also have a "database" of sorts in the origin file, which is #2326 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work on this! The level of machinery involved to plumb through new things like this is unfortunate; I was hoping to address that as part of work on #2326 but we should definitely land this first.
OK, got something that works pretty well now, so will start to split things out. The way I'm judging how successful this PR is for the compose side is by trying to express current RHCOS compose semantics via these new knobs. And with the latest here, we can now do that. (Edit: I realized I should add some context here: basically once rpm-ostree knows about modules, then current RHCOS composes break because it currently relies on rpm-ostree being non-modularity aware. One hack around this would be to spam diff --git a/rhaos.repo b/rhaos.repo
index c6781a2..4f03ed9 100644
--- a/rhaos.repo
+++ b/rhaos.repo
@@ -7,6 +7,3 @@
enabled=1
gpgcheck=0
baseurl=http://.../RHAOS/plashets/4.8-el8/building/$basearch/os
-# Exclude protobuf until:
-# https://issues.redhat.com/browse/ART-2355
-exclude=nss-altfiles kernel protobuf
diff --git a/rhel8.repo b/rhel8.repo
index f6aff14..25c5331 100644
--- a/rhel8.repo
+++ b/rhel8.repo
@@ -12,9 +12,6 @@ gpgcheck=0
baseurl=http://.../appstream/os/
enabled=1
gpgcheck=0
-# Exclude toolbox to make sure we use coreos/toolbox from rhaos repo
-# kata-containers wants non-modular libpmem
-exclude=conmon toolbox libpmem*module*
diff --git a/manifest.yaml b/manifest.yaml
index ad4cac0..54faada 100644
--- a/manifest.yaml
+++ b/manifest.yaml
@@ -31,6 +31,23 @@ repos:
- rhel-8-fast-datapath-aarch64
- rhel-8-server-ose
+repo-packages:
+ # we always want the kernel from BaseOS
+ - repo: rhel-8-baseos
+ packages:
+ - kernel
+ # there's an equal version nss-altfiles from RHAOS we don't want
+ - repo: rhel-8-appstream
+ packages:
+ - nss-altfiles
+ - repo: rhel-8-server-ose
+ packages:
+ # we don't want the modular version of this
+ - toolbox
+ # we want this one from RHAOS to make sure it's in sync with cri-o
+ # https://github.com/openshift/installer/pull/3062#issuecomment-582614009
+ - conmon
+
# We include hours/minutes to avoid version number reuse
automatic-version-prefix: "48.84.<date:%Y%m%d%H%M>"
# This ensures we're semver-compatible which OpenShift wants
@@ -254,6 +271,11 @@ packages:
# https://github.com/openshift/machine-config-operator/pull/2421
- conntrack-tools
+modules:
+ enable:
+ - container-tools:rhel8
+ - virt:rhel
+
packages-x86_64:
# Temporary add of open-vm-tools. Should be removed when containerized
- open-vm-tools I think some of these things we can clean up further, but at least we know we can express what we want. |
Rebased this now! Also now includes only enabling modules, e.g.:
This is now blocked on rpm-software-management/libdnf#1207. And also still need to add tests! |
ce20364
to
f3abc33
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only gave this a superficial skim so far but I think it's looking good!
75f7141
to
397227e
Compare
OK, now with more tests! This also requires rpm-software-management/libdnf#1278. There are a few more tests I'd like to add, and I also need to fix polkit interactions, but overall this is ready for more in-depth review! |
Ahh right OK. This is unblocked on the libdnf side, but I need to adapt things for the origin/treespec rework. |
Rebased! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! Really well done!
} | ||
} | ||
} | ||
|
||
gboolean we_got_modules = FALSE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Random aside, we can probably use more C++ for stuff like this, i.e. auto we_got_modules = false;
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I guess so. Though really the end goal is Rust anyway, so meh... slightly leaning towards sticking with gboolean
instead to be consistent.
@@ -601,6 +601,10 @@ typedef struct { | |||
char **install_pkgs; /* strv but strings owned by modifiers */ | |||
GUnixFDList *install_local_pkgs; | |||
char **uninstall_pkgs; /* strv but strings owned by modifiers */ | |||
char **enable_modules; /* strv but strings owned by modifiers */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated but I think this PR demonstrates really well we still have far too much "mechanical stuff" to plumb through to add new stuff like this. So many conversions from GVariant to C data types (char**
) back into GKeyFile
then back into char**
etc...with Rust and C++ in there too...
Hmm. You know what's tempting is to change UpdateDeployment
to go from GVariant a{sv}
-> Treefile
internally. That would be a huge step towards #2326 in letting the API take a new treefile directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing is that UpdateDeployment
is "delta-based", whereas Treefile
is about layering. E.g. we need to be able to say "stop layering this package".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, good point. We could at least represent additions via treefile. But maybe it'd be messier to have a half-declarative and half-imperative API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Random thought: We could have two treefiles: One for additions, and one for removals. The "removal" treefile would have
packages:
- foo
- bar
as usual, but the code would interpret it as things to remove?
The `:` character is shell-safe and needs no escaping. Prep for modularity, which uses colons a lot and so not escaping it will make `rpm-ostree status` cleaner.
Prep for using it in modularity code.
This stopped being used after coreos#2972.
We already query enabled repos higher up in this function.
That way, we don't e.g. have stale RPMs or tests in there.
Support for modules is something that has come up many times in the past. Most recently in FCOS: coreos/fedora-coreos-tracker#767 This commit adds support for both composing with modules on the server side and package layering modules (or just enabling them) on the client side. This doesn't support modules in `rpm-ostree compose extensions` yet, which is relevant for RHCOS. We can look at adding that in a follow-up.
Updated! |
Also discovered rpm-software-management/libdnf#1299 while respinning and testing this, but we don't strictly need it before merging. |
Hi, how can we include Modules (Like Clang) in our treefiles, we're building based on AlmaLinux and need a few |
Add support for composing with modules and for package layering modules
on the client-side.
This doesn't support modules in
rpm-ostree compose extensions
yet,which is relevant for RHCOS. We can look at adding that in a follow-up.