koji-devel March 2019

koji-devel@lists.fedorahosted.org

10 participants
7 discussions

SVG source for koji architecture diagram
by Ken Dreyer 30 Mar '19

30 Mar '19

Hi Mike, I was watching a YouTube video from Flock 2016. It was about "hacking on Koji": https://www.youtube.com/watch?v=RbEBYLSqFEc There's a slide presentation with a diagram of Koji. You made reference to doing this in Inkscape. Could you send me the source? Then we can put it into the docs at https://docs.pagure.org/koji/#koji-architecture - Ken

2 2

epel and mock bootstrap
by Dennis Gregorovic 25 Mar '19

25 Mar '19

Hi, On the Koji community call yesterday, a point was raised that mock bootstrap support[0] in Koji is needed in order to support epel 6 builds. I'd like to dive into that a bit more to better understand the problem and the options. Kevin, if I understand correctly, this would become an issue when F31 is deployed on the builders. About when would that be and when does epel 6 need to be supported until? -- Dennis 0. https://pagure.io/koji/issue/1017

5 4

koji brainstorming
by Ken Dreyer 21 Mar '19

21 Mar '19

Hi folks, I have some ideas about Koji development. I didn't want to throw a bunch of ideas up in the air without any code, but at the same time I did want to at least get the topics out there. Please let me know what you think! == API alternative to XML-RPC == From time to time I hear complaints about the XML parts of Koji. It's true that this is showing its age, but XML-RPC is a pretty mature solution with broad client support in a lot of languages that matter. Nevertheless I sometimes hear REST offered as a solution. I've worked with a couple services that added a REST API in addition to the original XML-RPC API, and unfortunately one of the biggest barriers to completely transitioning is all the dependencies. Koji's ecosystem is growing more and more as Koji's architecture becomes more modular and pluggable, and REST would "break the world". In some of these projects' cases that tried to transition, I suspect the projects themselves are going to die before they drop XML-RPC support. Moreover, there are some things that have no easy analog with an HTTP REST API: - Koji has a "list-api" RPC that automatically provides a list of all calls the hub provides. This is extremely useful when developing code and services that interact with Koji. There's nothing simple that gives us this same functionality out of the box. - Koji has multi-call support, allowing us to send multiple RPCs over a single HTTP request. This is critical to operating Koji at scale. The doing requests serially (or even parallelizing the on the client) is incredibly slow compared to the performance of multicall operations. Given Kojihub's single "large box" hub architecture, it's important to avoid hammering with more requests. It's the "XML" that's bad in "XML-RPC", and I am wondering if gRPC could be a good solution. I have not played around with it. There is slow progress towards developing GSSAPI authentication for this at https://github.com/grpc/proposal/pull/101 == Cheetah -> Jinja == Cheetah is essentially dead upstream and there is a lot of support behind the Jinja2 project. I could have sworn that I saw some patch from Tomas about this where he was experimenting converting over, but maybe I am imagining this. == SQLAlchemy == https://pagure.io/koji/issue/125 I expect an ORM would help with developer velocity and avoiding SQL injection in a lot of areas. Koji has its own "history" helper methods to record an audit trail for some changes in the database. I've had some good experience on a small project using https://pypi.org/project/sqlacodegen/ to reverse a pre-existing schema into a series of SQLAlchemy model classes. I think a SQLAlchemy transition could be 1) swap out the psycopg connection code to use SQLAlchemy connections instead, and pass all raw SQL into the SQLalchemy connection 2) use sqlacodegen to migrate to using rich models over time. == pytest == Currently the Koji tests use Python's unittest framework, and pytest would let us have advanced features and cut out a lot of the boilerplate. pytest is able to execute unittest's tests, so that would help with the transition instead of having to cut everything over all at once. == Dynamic builders == If Koji's task queue grows beyond what the static list of builders can handle, there's no way to "burst" to a cloud environment to dynamically add and remove builder capacity. I have been brainstorming some kind of an "orchestrator" that can create the necessary builder credentials and authorize the builders into the hub. It would need an ability to add and remove Kerberos principals for each builder's FQDN, or maybe not? Maybe this could be implemented as an OpenShift operator. == Event-driven architecture == Currently Koji polls a lot. This puts pressure on the hub to continuously answer all the poll requests from the CLI, web interface, kojid, etc. Big environments have to tune the kojid's sleep time to use longer timeouts, which means kojid picks up new builds slowly. In other projects celery with rabbitmq has been a great combination for dispatching jobs to workers. I think celery could be a good choice for Koji as well. == Stronger checksums == While I was working on content generators, I found Koji relies on md5 in several areas. This hash is very broken and we'll need a new one. It would be ideal to have a tool that can scan every existing build archive, calculate the new hash values, and add the new hash values into the database. == Longer GPG key lengths == Koji currently stores short key IDs. This has ramifications for Pungi, productmd, and probably lots more, because they all get these key values from Koji. The evil32.com website explains the problem with these short key IDs, and I'm surprised we don't have attacks on Red Hat's keys already in this area. == Storing builds in object storage (S3) == Koji assumes a sizable NFS architecture, and in many environments object storage like S3 is more attractive and scalable. There are a couple open-source implementations of S3's API, like Ceph. Maybe S3 buckets could be another "volume" type for the Koji hub. I haven't looked in depth at what this would mean for how Koji manipulates builds (eg with createrepo). - Ken

5 4

Koji Community Meeting Notes - Mar 20, 2019
by Yuli Wang 21 Mar '19

21 Mar '19

*Meeting Time:* Mar 20, 2019 10:00AM-11:-00AM in US *Where: **https://bluejeans.com/1265288041* <https://bluejeans.com/1265288041> *Recordings:* https://bluejeans.com/s/KLdqP/ *Attendees: * Ken Dreyer, Neal Gompa, Yuli Wang, Brendan Reilly, Chris O’Brien, Jana Cupova, Mike McLean, Nick Burr, Tomas Kopecek, Dennis Gregorovic, Yu Ming Zhu, Scott Miller, ahills@, Kevin Frenzi *Meeting Notes:* 1.Koji update: - Koji 1.17 released on Mar 6 , 2019 - https://docs.pagure.org/koji/release_notes_1.17/ - Highlights: - py3 support! (woot) - except for image building as ImageFactory doesn't have py3 support yet. Need to figure out a plan for that - There is a PR available, but it needs testing - Critical CVE fix - A few API changes (mostly tech debt reduction) - Feedback - Neal deployed it shortly after release and stuff didn't explode! It's a simple setup, but still good to hear. No need for image building - Fedora is in Beta freeze now so 1.17 hasn't been deployed yet but should be deployed right afterward - *Retrospective:* - Neal: 1st half of dev cycle was quiet in terms of feedback but 2nd half was very responsive - Ken: Great to see regular releases - Update problems - 1.16 -> 1.17 upgrade was smooth - Koji 1.18 planning - https://pagure.io/koji/roadmap/1.18/ - Issues priority pending review - Dennis - https://pagure.io/koji/issue/1204 RFE: let users opt out of notifications - Neal: doesn't impact them currently but would like to see this and have the ability to only get email on build failures - Andrew: useful for people who are set as owners on thousands of packages. mikem: +1 - https://pagure.io/koji/issue/887 User CLI plugins - useful when using virtualenv (e.g. during development) - longer-term, may want to explore entry points (or some other way) of adding plugins - There is a meta-plugin today that does support entrypoint plugins - https://github.com/obriencj/koji-smoky-dingo/blob/master/koji_cli_plugins/k… - https://pagure.io/koji/issue/618 Improve flexibility to generate mock config file - There is an RFE from neal for having macros per tag. Not the same as this, but similar - https://pagure.io/koji/pull-request/898 - Last thing that Neal needs before POC mageia - https://pagure.io/koji/issue/596 koji mock-config always outputs rpm build configs - https://pagure.io/koji/issue/340 koji doesn't take plugins into account when median capacity is calculated - Mike to do more investigation to see whther this is needed in 1.18 or wait for larger scheduling refactoring - https://pagure.io/koji/issue/1225 Add policy test for btype - Buildroot improvements 2. Community feedback / input - koji brainstorming discussion in mailing thread - *Ken Dreyer* - https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.… - How do we lower the barrier to entry? The Koji core dev team itself is small, but the community / user base is very large - Neal: need to make it easier to stand up an instance from scratch to increase adoption and awareness - Neal: would be great to have more public instances so that we can see all of the use out there - Could we have a public bug scrub? - Have a healthy, accurate backlog. Regular grooming. Have a place for people to bring attention to issues - Could bring in rotating set of developers from constellation of teams (osbs, bodhi, pungi, koschei, MBS, centos, etc) - Would need to identify this list. Ken & Neal can help with talking to people. Eg OSBS could be Luiz Carvalho or someone from his team (Martin Basti?). Pungi could be Lumbomir Sedlář. Bodhi could be Randy Barlow, koschei could be Mikolaj Izdebski, MBS could be Jan Kaluza, CentOS could be Thomas Oulevey and/or Brian Stinson. - Would be great to have this in the docs as well. - mikem: here's a talk about Koji infra at CERN: https://youtu.be/RrA6TKDi4p8 - mikem: and one on the CentOS communit build system: https://archive.fosdem.org/2015/schedule/event/_centos:_community_build_ser… - Neal / mageia - https://pagure.io/koji/pull-request/898 is top RFE - may need guidance on how to use svn - Fedora / Mageia - bootstrap chroot is going to be needed for EPEL builds as YUM goes away in Fedora - when builders are deployed with F31, EPEL 6 will break, or at least not work as expected (differences between yum dep resolution and dnf dep resolution) - Mageia prefers bootstrap chroot style builds too - Fedora - https://pagure.io/koji/pull-request/1273 is of some interest - There are teams that want to be able to query for build dependencies (rust, koschei, ...) - today, srpms are mixed in. would be helpful to have a separate repo - need to keep an eye on performance - mergerepos_c changes for modularity (no issue or pr yet, still being discussed) - treating modular repos as regular repos *Action Items:* 1. Ken & Neal help with talking to people from different team to identify issues list. 2. Mike Double Check Koji1.18 planning. Thanks Yuli

1 0

Upcoming Koji Community Meeting on Mar 20, 2019
by Yuli Wang 18 Mar '19

18 Mar '19

Dear, All We plan to hold the 1st Koji community meeting after Koji1.17 release, Also there are some discussions on Koji planning, let's talk more in this meeting. Here is *meeting reminder* in case someone didn't get or note the meeting invitation: *Meeting docs: **https://public.etherpad-mozilla.org/p/KojiMar2019 <https://public.etherpad-mozilla.org/p/KojiMar2019>* *Meeting Time:* *Mar 20* 2019 10:00-10:40AM US/ET *Where: * https://bluejeans.com/1265288041 *Proposed Agenda:* - Review last action items - n/a - Koji update: - Koji 1.17 released on Mar 6 , 2019 - https://docs.pagure.org/koji/release_notes_1.17/ - Highlights: - - Retrospective - - Update problems - - Koji 1.18 planning - https://pagure.io/koji/roadmap/1.18/ - Highlight - - Requests: - - Community feedback / input - koji brainstorming discussion in mailing thread. Feel free to add more topics you want to talk. Thanks, Yuli

1 0

Re: F30 Self-Contained Change proposal: Retire YUM 3
by Dennis Gregorovic 07 Mar '19

07 Mar '19

On Fri, Mar 1, 2019 at 4:25 AM Michal Domonkos <mdomonko(a)redhat.com> wrote: > On Fri, Mar 1, 2019 at 2:24 AM Dennis Gregorovic <dgregor(a)redhat.com> > wrote: > > > > I have an update on the koji end. The 1.17 release will not only drop > the yum dependency, it will also have full python 3 support (except for > image building that uses oz / imagefactory). Unfortunately, there is only > medium confidence that the 1.17 release will be ready by the F30 devel > freeze on Tuesday. It depends on whether QE uncovers any issues in its > final testing. If we're not able to land the release on Tuesday, what is > the backup plan? > > I suppose you're concerned about the Python 3 support part and not > about the DNF port, but in case it's the latter -- please note the YUM > deprecation has been approved for F31 (and is already happening in > Rawhide now) as opposed to F30, to give everyone a bit more time to > finish their porting efforts. > Ah, I didn't know that! In that case, we'll still try to land koji 1.17 for F30 if we can, but we'll make sure that it's had sufficient testing and not rush it out prematurely. Also, I forgot to include koji-devel@ on the previous emails. Looping in that list now.

1 1

Koji 1.17.0
by Michael McLean 06 Mar '19

06 Mar '19

Koji 1.17.0 is out. Thanks to everyone who contributed! You can read the release notes here: https://docs.pagure.org/koji/release_notes_1.17/ Highlights: Fix for CVE-2018-1002161 Full python3 support You can view the 1.17 roadmap at https://pagure.io/koji/roadmap/1.17/ For the current roadmap, see https://pagure.io/koji/roadmap You can download this and other releases here: https://pagure.io/koji/releases

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

koji-devel March 2019