[RFC] test: test against reference images lib generated manifest #186
Conversation
|
Super nice, can't wait to see where this goes. |
We need this to generate bit-by-bit compatible manifests from otk to the ones that `images` generates. See also osbuild/otk#186
We need this to generate bit-by-bit compatible manifests from otk to the ones that `images` generates. See also osbuild/otk#186
This commit adds a new "make externals" command that should help iterate faster by making the images otk externals available easily for development.
This commit updates the example partition table in the centos-9-x86_64-qcow2.yaml file to "work", i.e. to generate working otk defines. It is not a complete partition table yet. Note that this will need a fix in images to really work: osbuild/images#890
This is an idea how to make development of the otk manifest easier to iterate on. The idea is that we filter out the sources/rpms (we should consider later to keep the rpm names but not the exact versions) and then compare the stages. This way we can iterate on the development of the centos-9 example and always be confident that the reference is matching. The reference was generated with the `images` library.
This commit is a lesson from osbuild/otk#186 as it is right now extremly easy to crash the otk disk externals with bad inputs. This commit adds basic input validation, it's probably a good idea to also go deeper into the library and make it less trusting about pointers but that is (slightly) orthogonal.
| stages: | ||
| - type: org.osbuild.kernel-cmdline | ||
| options: | ||
| root_fs_uuid: d8bb61b8-81cf-4c85-937b-69439a23dc5e |
There was a problem hiding this comment.
are we already that far with otk to generate this number in a variable (dynamically) and use it below?
…mainly to demonstrate this functionality - this might be too far from the current issue, so you can as well ignore this comment
| stages: | ||
| - otk.include: "fragment/kernel-cmdline.yaml" | ||
| - type: org.osbuild.rpm | ||
| - type: org.osbuild.fix-bls |
There was a problem hiding this comment.
extracting: org.osbuild.fix-bls,org.osbuild.keymap, org.osbuild.timezone would work here but because it's in a list it will look quite awkward
There was a problem hiding this comment.
It won't be that awkward, I believe we already use otk.op.join in some places and I used it 'everywhere' in my branch just so fragments could define one or more stages :)
| - reboot.target | ||
| - tuned | ||
| default_target: multi-user.target | ||
| - type: org.osbuild.selinux |
There was a problem hiding this comment.
this should be split into a fragement as it's use with the same options everywhere
There was a problem hiding this comment.
Not entirely, we'd need separate fragments for the build and root pipelines as the build pipeline also sets install_t on cp, so maybe two fragments? :)
This commit is a lesson from osbuild/otk#186 as it is right now extremly easy to crash the otk disk externals with bad inputs. This commit adds basic input validation, it's probably a good idea to also go deeper into the library and make it less trusting about pointers but that is (slightly) orthogonal.
This commit is a lesson from osbuild/otk#186 as it is right now extremly easy to crash the otk disk externals with bad inputs. This commit adds basic input validation, it's probably a good idea to also go deeper into the library and make it less trusting about pointers but that is (slightly) orthogonal.
|
All the relevant parts of this PR got extracted into smaller PRs with proper commits so this one can be closed. |
This is an idea how to make development of the otk manifest
easier to iterate on. The idea is that we filter out the
sources/rpms (we should consider later to keep the rpm names but
not the exact versions) and then compare the stages. This way
we can iterate on the development of the centos-9 example and
always be confident that the reference is matching.
The reference was generated with the
imageslibrary.The next step would be to do the partition table with this, then
split out stages etc.