-
Notifications
You must be signed in to change notification settings - Fork 9
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
rewrite depsolve external #196
Conversation
5beb39b
to
5af9a2b
Compare
75dd20c
to
c6655c9
Compare
Needs:
|
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.
Thank you! It's super nice to see this coming together. A few suggestions/ideas inline for your consideration.
src/otk_external_osbuild/command/depsolve_dnf4_gen_curl_source.py
Outdated
Show resolved
Hide resolved
Fwiw, I think the schema is fine in a followup as e.g. images or osbuild do not use dnfjson schemas either. |
55cb4e0
to
71891bd
Compare
|
9364c37
to
0223a56
Compare
This commit adds a new `normalize_rpm_refs()` helper that will normalize the rpm file inputs for comparison, i.e. it will sort the hashes and remove duplicates. This is important because the "images" library writes duplicated input rpm packages from the inputs as duplicated hashes into the references. But in our test we only need to worry about that exactly the right rpm files got included, the order is not important.
Remove unused subcommands of the `osbuild_external`. Signed-off-by: Simon de Vlieger <[email protected]>
Externals no longer receive their name within the tree structure that they get from `otk`. Signed-off-by: Simon de Vlieger <[email protected]>
This splits out the depsolve external along the lines of the previously written partition externals. Using the external is now a two-step process where you run one external in a define and then use its output to generate stages and sources. Signed-off-by: Simon de Vlieger <[email protected]>
Use depsolver for the CentOS 9 QCOW and AMI omnifests Signed-off-by: Simon de Vlieger <[email protected]>
In `images` we mock depsolves so we can run them very fast under test. This introduces the same functionality to the depsolve external. Signed-off-by: Simon de Vlieger <[email protected]>
Use a `const.internal` subkey for the dnf4 depsolving external. This follows the ideas set forth in the partition tables. `.const` means that the format can be considered un-changing and `.internal` means that this shouldn't be used directly but only through other externals in the same group. Signed-off-by: Simon de Vlieger <[email protected]>
Renames the depsolve externals to fit into the partition externals naming scheme. Signed-off-by: Simon de Vlieger <[email protected]>
Bit of a hacky way to copy the (installed) Python externals into the search path for the manifest tests. Also sets testing environment to True. Signed-off-by: Simon de Vlieger <[email protected]>
Signed-off-by: Simon de Vlieger <[email protected]>
Properly output the RPM stage. Signed-off-by: Simon de Vlieger <[email protected]>
Drop the second GPG key as they are not in the reference manifests. Signed-off-by: Simon de Vlieger <[email protected]>
Signed-off-by: Simon de Vlieger <[email protected]>
4c83c00
to
4428e7e
Compare
Provide a map keyed by package name of the depsolve result that can be used by omnifests to look up package information. Signed-off-by: Simon de Vlieger <[email protected]>
I've opted for a very similar approach to Perhaps we only want the (N)EVRA in there? |
With the rewrite of the depsolver these are not extremely poc anymore. Signed-off-by: Simon de Vlieger <[email protected]>
Signed-off-by: Simon de Vlieger <[email protected]>
- tar | ||
- tuned | ||
- tcpdump | ||
exclude: |
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.
Finding a way to test this would be really good, this will probably require changes in the gen-manifests
mock dnfjson mode in images though so probably followup material but IMHO quite important to ensure we really have the same images.
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.
Thanks, this moving along nicely, some comemnts inline.I really want to look a bit more at the gen-manifests reference image generator to get more meaningful mock data, right now we do not test anything like excludes or we don't mock versions or arch which is important for the testing of the grub2 kernel bits.
# other externals. | ||
data["tree"]["const"]["internal"]["packages"] = packages | ||
|
||
# We also store all resolved packages and some meta information about |
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 adds a very broad API to this otk external, I personally would start more targeted, we need the kernel name and version and in images
the kernel is handled specially only. So maybe we could do the same here? Something like just expose a const.kernel.{name,version}
? We will need to adjust fragments/grub2.yam
to match the kernel and the string there includes 0-0.noarch
right now which also indicates that we need to tweak our tests to make this better testable.
Here is an alternative idea 5f378bb
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.
We can set mock data to always be 0
, 0
, and noarch
instead of the empty strings they are now.
I chose the broad API to not limit ourselves here also taking some inspiration from osbuild-mpp
where it is currently possible to get the version of any 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.
I've done the former bit and use that information in the example; it's a tiny bit tedious and maybe we want to assign separately in the define. Not that important to me right now.
The discussion about if this API is too wide needs to be resolved as well :)
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.
Thanks, that is interesting! How is this used by folks that use osbuild-mpp
- are there more use-cases then the kernel and if so, which ones? Would love to learn more here.
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 only call to the equivalent function in images that's not for looking up the kernel is to check if dracut-config-rescue
exists in the package set, but it doesn't care about version.
https://github.com/osbuild/images/blob/67a2b2f65a2e0969039a3de17bf2c266390d01ab/pkg/manifest/os.go#L651
I can imagine a case where this might be useful. We've never had to do this but perhaps a stage's options might change depending on the version of a given package (in the build root or in the OS).
I lean towards simplicity for these externals, but I also like the generalisation of being able to "query" for any package's version by name. It feels useful, so my instinct right now is to generalise it so it's easier to grow in the future.
Signed-off-by: Simon de Vlieger <[email protected]>
Addressed the mock thing in a separate commit (can be squashed if we want) but keeps the review a bit cleaner for now. Last outstanding thing is the package versions, do we want all of them to be available of just the provided kernel package name? |
Use the depsolved kernel version and release for grub. Note that this assumes there is a `packages.os` which might not be true for all situations. Perhaps this should be a separate define in the examples. Signed-off-by: Simon de Vlieger <[email protected]>
daffa31
to
a7b8a91
Compare
This PR splits out the depsolve external along the same idiom that the partition externals follow. Draft because it needs a manifest as well.