bib: run "dnf" inside the container again #670
Conversation
mvo5
force-pushed
the
bib-container-dnf-test3
branch
from
25e576e
to
ca0a1e9
Compare
| matches, err := filepath.Glob("/etc/pki/entitlement/*.pem") | ||
| if err == nil && len(matches) > 0 { |
There was a problem hiding this comment.
What does len(matches) > 0 mean here? That the machine is already subscribed?
There was a problem hiding this comment.
Yeah, it's basically just double checking if the machine is subscribed already (because the helper unsubscribes machines that got subscribed just for the test again), actually there should be a comment to explain this and a "XXX: find a better way", I had trouble finding some machine readable API and stuff like "subscription-manager status"/"list" is both slow and hard to parse. But maybe I'm missing something :/
bib/internal/container/container.go
Outdated
| // XXX: hardcoded python3.12 | ||
| if err := c.CopyInto("/usr/lib//python3.12/site-packages/osbuild", "/"); err != nil { |
There was a problem hiding this comment.
What's the long term plan for this?
There was a problem hiding this comment.
A good question, I think we need to have a brainstorm about it - one way would be to just make it a single file script again another to find/fix the root cause why "dnf.SetRootdir()" does not work with subscribed content.
There was a problem hiding this comment.
find/fix the root cause why "dnf.SetRootdir()" does not work with subscribed content
Need me to look into this? It sounds like we have a bug here in the depsolver.
There was a problem hiding this comment.
@achilleas-k Sure thing, feel free to look at this, I'm very curious. The easiest is to start from a subscribed machine, then revert 3540536 and run (as root) cd bib/internal/cntdnf && go test -v
mvo5
force-pushed
the
bib-container-dnf-test3
branch
from
a058d4d
to
3318a42
Compare
In 17d3b56 osbuild-dnf-json was changed to run outside the container. This lead to a regression in accessing subscribed content. This commit partially reverts this commit to run dnf again inside the container so that we have access to the /run/secrets and RHEL repos.
This commit adds a test that ensures that InitDNF() results in triggering the dnf plugin that updates the subscriptions.
This commit adds a test for the DNF solver inside a subscribed RHEL container.
This commit moves the logic of dealing with `osbuild-json-dnf` for containers into a new container dnf `cntdnf` go module. Also move the integration test for dnfjson with subscribed/normal content there.
This commit wires up the needed credentials and scaffolding to
run the integration tests about subscribed content in containers
via tmt. For this it passes in the `RHSM_{ORG,ACTIVATION_KEY}`
secrets and runs the go tests as root.
This splits the go unit tests into a new github action to avoid
having to wait for both to finish.
For unknown and inexplicable reasons the progressbar does not generate output when run with testingfarm. This is not observed on a normal fedora40 or the GH runners, the reason is unknown and should be investigated but to unblock us the test is currently disabled in this specific environment.
mvo5
force-pushed
the
bib-container-dnf-test3
branch
from
3318a42
to
1362165
Compare
| @@ -0,0 +1,43 @@ | |||
| --- | |||
| name: Testing farm go unit tests | |||
There was a problem hiding this comment.
This duplication is sad, we should look into something like actions/starter-workflows#245 (comment) here too.
Ondrej suggested to remove the `cntdnf` package again and move the code back into container. My original thinking was to have a separate package because it a "container" should not need to have knowledge about dnf and we could have a `cnfapt` later but then YAGNI and we can always split it out later.
In 17d3b56 osbuild-dnf-json was changed to run outside the
container. This lead to a regression in accessing subscribed
content. This commit partially reverts this commit to run
dnf again inside the container so that we have access to
the /run/secrets and RHEL repos.
This also adds a bunch of extra tests that needs to run
on a fedora/rhel/centos machine to test dnfjson and
subscriptions inside the container environment. Those
will only run in testingfarm (or locally) not in GH actions.
Closes: https://issues.redhat.com/browse/BIFROST-429
P.S. We should probably also look into how to inject osbuild-dnf-json into
the container, this way is not ideal, we maybe need to reconsider
putting it all into a single file again or think about other ways to make
this slightly easier. The tests/refactor hopefully makes this slightly easier
now.