Dne 08. 03. 25 v 15:11 Colin Walters napsal(a):
On Sat, Mar 8, 2025, at 2:50 AM, Richard W.M. Jones wrote: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.One very important thing to understand here is that Konflux is built on *top* of https://tekton.dev/ which itself is built on top of Kubernetes https://kubernetes.io/ which are well documented and established FOSS projects used by multiple organizations, with a wealth of knowledge and tooling built on top of both of them.
If "Tekton" click for you, it does not click for me. Opening the https://tekton.dev/ provides no more information. Richard asked several questions:
~~~ This doesn't really help with the "what". I work at Red Hat and still have no idea what Konflux actually is. 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? ~~~ This can be applied to Tetkon. If I browse to e.g. https://tekton.dev/docs/getting-started/tasks/It immediately suggest to install `minikube` and what not. But I'd likely be just a user.
Even if I go to the Fedora Konflux instance: https://konflux.apps.kfluxfedorap01.toli.p1.openshiftapps.com/application-pipeline/ I can't see anything useful there (except spinner). So can I look at some (useful) UI, is there some CLI or something tangible? Vít
Which is not true of Koji. Just one example: In the past we've hit issues where some RPMs take a lot more CPU/RAM to build than others. In Kubernetes, projects like https://github.com/kubernetes/autoscaler/tree/9f87b78df0f1d6e142234bb32e8acbd71295585a/vertical-pod-autoscaler exist to automatically track and scale the requested resources for pods (containers) based on historical or inferred usage. Because Tekton builds (tasks) are just pods ( https://tekton.dev/docs/pipelines/podtemplates/ ) these techniques work for them. But for Koji, there's no such ecosystem, and only ad-hoc bespoke ways to tell the system how much resources a particular build requires. Strongly related to this is that Koji is a bespoke task manager mostly used to build RPMs, but has little to do with running generic workloads (especially relevant: integration tests running in containers) so we end up with disjoint infrastructure. With Tekton it's way more obvious how to e.g. build a container (or an RPM which is installed into a built container) and then run tests on that container before e.g. promoting it on, within the same cluster or CI job.
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
