modularity support #1197
modularity support #1197
Conversation
|
|
supakeen
force-pushed
the
modularity
branch
6 times, most recently
from
77b98a8 to
2727433
Compare
|
Now has a test config; has a (quick) test if stages get injected (thanks to @mvo5) and I'll be adding some stage tests. |
| failsafeDir, err := fsnode.NewDirectory("/var/lib/dnf/modulefailsafe", nil, nil, nil, true) | ||
|
|
||
| if err != nil { | ||
| panic("failed to create module failsafe directory") | ||
| } | ||
|
|
||
| pipeline.AddStages(osbuild.GenDirectoryNodesStages([]*fsnode.Directory{failsafeDir})...) |
There was a problem hiding this comment.
Would it make sense to make this conditional if len(failsafeFiles) > 0 ?
There was a problem hiding this comment.
It could be; but it'd be an error to not have any failsafeFiles when there were modules in the depsolve result.
| "blueprint": { | ||
| "packages": [ | ||
| { | ||
| "name": "@nodejs:18" |
There was a problem hiding this comment.
We will need a way to enable a module in the BP and install a specific package from it in the packages section, right? You could then extend https://github.com/osbuild/images/blob/main/test/scripts/base-host-check.sh to check for the created module files on the OS. I mean, you could do that even in this scenario.
There was a problem hiding this comment.
I thought we were skipping that part of it in favour of doing everything through module names in the packages; if we also want to support the former (probably up to the frontend?) in blueprints then yes it needs to be expanded.
cc @croissanne / @lucasgarfield?
There was a problem hiding this comment.
My understanding was that some modules do not have any default profile or any profile at all. If you want to install a specific package from that module and a specific stream, you'd need to enable it explicitly. I thought that was the whole point for adding module-enable-specs to the depsolve request 🤔
What this manifest gen does was possible before the modularity work landed, just the resulting OS image would not have the proper module enabled and the package marked as coming from it. However, this does not change anything from the point of view of what the user can do with modules.
While we can probably hide module enabling when using via CloudAPI, it seems to me that we should somehow test it anyway, even if we end up not exposing it in the BP.
There was a problem hiding this comment.
Right, the important part I to me was that the built images know that, and which, modules have content installed which we do through the module configuration and fallback files.
Which bits are enabled here in this PR is entirely up to the workflow the frontend wants to use, in my opinion. If it wants to show available modules and install them directly (the usecase currently satisfied in this PR) or if it'd show available modules and selecting them then allows you to select packages from those modules (the usecase that would need enabled-modules).
I can add the enabled-modules and its testcases but if it's surface area that isn't going to be touched then I'd prefer to not do that (yet).
There was a problem hiding this comment.
So I think in the UI we'll actually avoid installing module packages 'by the (whole) module'. We'll just continue with package search as usual, except for module packages we'll select the latest supported version by default or they can select another version and mark them as supported or not. So that means from composer and images pov we'll be enabling modules by hand and then installing individual packages from them.
There was a problem hiding this comment.
Then I'll be adding/exposing the enabled modules as well.
Signed-off-by: Simon de Vlieger <[email protected]>
Include any module results in the result object for inputs. Signed-off-by: Simon de Vlieger <[email protected]>
Provide the DNF module configuration stage which allows to write modularity related configuration files for DNF. Signed-off-by: Simon de Vlieger <[email protected]>
Generate stages for files and directories based on the data returned by the dependency solver for the enabled modules. Signed-off-by: Simon de Vlieger <[email protected]>
Add a modular user-requested package build for the CentOS 9 qcow2 image to verify that it installs. Signed-off-by: Simon de Vlieger <[email protected]>
Tests the conditional that if `moduleSpecs` are set the appropriate module config stage is injected. Can be expanded later. Co-authored-by: Michael Vogt <[email protected]> Signed-off-by: Simon de Vlieger <[email protected]>
When modules are installed verify that the modularity related files are present on a system. Signed-off-by: Simon de Vlieger <[email protected]>
Adds modularity support to
images. Needs tests.