On Sat, 8 Mar 2025 at 02:52, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
On Fri, Mar 07, 2025 at 12:56:21PM -0800, Brendan Conoboy wrote:
>
> A few weeks back I started a discussion about accidental secrets,
> using Konflux as an example. Now that FOSDEM has come and gone, I’d
> like to take the topic further. If you’re not familiar with it,
> in its own words, Konflux-ci “is an open source, cloud-native
> software factory focused on software supply chain security”, but for
> the sake of this discussion, it’s probably better to think of it as
> “the aspirational replacement for the myriad build and CI systems
> Red Hat uses in all its products”. Aspirational is key- we aren’t
> there yet… and it’s going to take a while to get there.
This doesn't really help with the "what". I work at Red Hat and still
have no idea what Konflux actually is.
Having tried to dive into Konflux for a bit, I think the major problem is that it keeps getting referred to in the wrong format. It isn't a koji replacement, it is a Fedora Build System replacement. The Fedora Build System is not just koji but it is a very large list of tools which mostly work together to produce a large number of different outputs ranging from source code storage (pkgs and backend storage), rpms (koji->mock), containers, isos, etc and a lot of logs for different systems. Then there is testing (via autoqa, osci, and whatever else) and confirmation of testing coordinated by bodhi. All of these are coordinated by different message buses and command and control systems depending on where it is going on. [I tried twice to map the system twice and had to give up because there are a lot of little things which actually rely on other parts but you only know it when they break versus in motion]
Many of the applications are written as either proof of concepts which became production or one-offs which were built for a specific task but shoe-horned into the system as a whole. Try to add in a new 'tool' and you have to retool dozens of different applications which now have to deal with new messages, timing, inputs, etc. And once you have retooled then you end up spending a lot of time finding dozens of edge cases which take up a lot of time and energy.
If the Fedora Build System were a real-world company, it would be a couple dozen workshops all bought at different times sort of working together as best they can but very hard to map out when and where any two departments need to talk with each other or what they can. This leads to a lot of starved resources at different times where various 'limited' resources strangle each other time and time again as new edge cases or different expected outputs are added.
The idea for 'Konflux' is to try and redesign the factory by first making everything 'visible' and using the same backbone resources. As I read through various things, I see certain parallels between it and microkernel operating systems. If my view is somewhat correct, then Konflux is a micro-kernel which will primarily do the low level resource and message passing that the various internal services are plumbed into. Other parts would be done in purpose written services which are meant to do one thing only. Some other tooling inside would be checking in/out source code, setting up builders, sending source and different spec files to the builder, sending the outputs to a testing system, getting the passed material to its next 'destinations'. These would all be 'registered' and their interactions should be 'visible' so that if XYZ is broken we know that ABC may still work but EDF won't
This is meant to cut down a lot of failure modes where people will argue over that the build system is broken or not because they are looking at two different things which look like they are dependent but aren't.
Now I am not saying that Konflux is a good thing or a bad thing. My knowledge of Konflux is limited as I agree it isn't something easy to run yourself. But neither is the Fedora Build System. You can set up koji or src or some other parts but there is a reason it takes a rack of systems running many virtual machines to actually get a finished build out.
For Koji I can take a look at the web interface:
https://koji.fedoraproject.org/koji/
and kind of get the gist of what's going on. Or to be a bit fairer as
many here are already familiar with Koji, SUSE's build system web
interface:
https://build.opensuse.org/
Where's the web interface of Konflux? Where can I explore what it's
doing / building right now?
> Despite many months of development, rpm support is just now being
> plumbed into the system (containers happened first). In fact, at
> this year’s CentOS Connect had Mike McLean, lead developer of koji,
> presented “Building RPMs with Konflux
>
> ”. In his talk he related some of the details about the interim rpm
> approach, which injects builds into the koji after a build is
> complete. This seems weird, but it makes sense: When your goal is to
> eventually replace the full pipeline, but it’s going to take a long
> time, you have to write some throw-away code that bridges new to
> old.
I didn't watch his talk, but this all sounds very vague. And that the
fact that it's "container first" and an internal project first is
worrying too. How does it build containers without starting with
RPMs? Where do those RPMs come from?
TL;DR, I don't know what this is.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
_______________________________________________
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
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ 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
