Hi Adam and Ben! On Mon, Jun 26, 2023 at 10:14 PM Adam Williamson <adamw...@fedoraproject.org> 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: @ad...@fosstodon.org > 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 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
