Hi Adam and Ben!
On Mon, Jun 26, 2023 at 10:14 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
In terms of testing: we already test the existing toolchain pretty
effectively in practice. openQA builds Workstation and KDE live images
with every relevant critical path update. If an update breaks live
image creation, we find out about it right away, and the update is
gated.
Can you elaborate the testing setup more? Does openQA somehow call livemedia-creator locally, or does it just offload the task to koji? If the latter is true, that this shouldn't be an issue. The former option is more tricky, we would have to somehow adjust openQA to use a different tool.
In terms of file formats: is toml really that much better known or
better than kickstart, for an audience of Fedora devs, for the purpose
of building a live image? Especially now we (finally) got the livesys
stuff out of the kickstarts and they're mostly pretty simple? As a
specific nitpick, the documentation on the Image Builder format makes
it clear that it supports comps groups, but it's less clear if it
supports comps *environment* groups. It really needs to do so to
maintain parity with livemedia-creator; we don't want to have to define
all the environment groups twice (once in comps, once in imagebuilder
TOML files). If it does support this, it should be made clear in the
docs.
Yes, it does support environment groups.
Regarding kickstarts vs. blueprint (TOML): From my point of view, kickstarts are a specific thing to the "Fedora ecosystem", whereas TOML is widely used also in other areas (Go/Rust), thus there is a bigger ecosystem of tooling for it. I would also like to introduce JSONSchema (conversion between JSON and TOML is mostly lossless) for blueprints, which would allow e.g. linting of blueprints. Yet another step in making the tooling more user-friendly. Anyway, I don't want to spend much time on this, it feels like this is more a matter of taste.
I notice the Change doesn't say much about debugging failed builds.
This is very important. Failed livemedia-creator tasks are quite easy
to debug. livemedia-creator as run in Koji by Pungi is very good at
providing sufficient logs to determine what the heck went wrong if an
image build fails. Other tools - notably ImageFactory - are notoriously
much worse at this. Where does Image Builder fall?
Let's talk about this in the branch about logs in koji.
As I said, I'm not saying we shouldn't do this. But I do think that if
it doesn't provide any really compelling benefits over livemedia-
creator, we should set a high bar for it also not having any
significant *drawbacks* compared with livemedia-creator.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx
https://www.happyassassin.net
> Ben Cotton:
> What's the impact to QA and release processes? Will the Workstation
> images still be in the regular large compose, or will they be a
> separate compose that will need to be managed independently?
> images still be in the regular large compose, or will they be a
> separate compose that will need to be managed independently?
Images will still be in the regular compose, image builder can be just called via Pungi, so one compose can use multiple image building tools.
Regarding the impact: I'm mostly concerned about the openQA workflow, see the paragraph above.
Cheers,
Ondřej
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
