On Sat, 8 Mar 2025 at 02:52, Richard W.M. Jones <rjo...@redhat.com> 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@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
>


-- 
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@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

Reply via email to