Koji Community Meeting Notes on Nov 20, 2019
by Yuli Wang
*Attendees: *Ken Dreyer, Kevin Fenzi, Tim Waugh, Tomas Kopecek, Dennis
Gregorovic, Jana Cupova, Brendan Reilly, Jim Foraker, MIke McLean, Chris
O'Brien, Nicholas Burr, Michal Faruga, Scott Miller, Yu Ming Zhu, Neal
Gompa, Jon Disnard, Jon Schlueter
*Meeting Summary: *
There are 8 users besides brew/koji development team in this meeting, we
shared what has been released and got feedback on Koji1.19 & Koji1.19.1,
collected the requirements for Koji1.20, discussed if koji support RHEL6
and how to coordinate with QE on the integration testing. More details
please check the meeting notes.
*Meeting Notes: *
- Koji update:
- Koji 1.19 released
- 51 closed issues
- about three months since 1.18 release
- Koji 1.19.1 (bugfix release)
- Feedback or retrospective
- Neal hasn't had a chance to try it out yet but is glad about the
responsiveness and cadence of releases.
- Proposed issues so far - https://pagure.io/koji/roadmap/1.20/
- code freeze: start of Jan.
- release plan by the end of Jan.
- MBS plans progress
- still in progress, Brew start from Q4
Should we keep RHEL 6 support? (ie py26 support). When can we drop it?
Another way of framing this is dropping python 2 support.
EPEL 7 has support for python 3 (mock, etc)
[kevin] This could be a bigger gain
[ktdreyer] Yeah, I think we should keep the RHEL 7-based packages on
py27 for the next year (at least). Jumping completely to py3 on el7 is a
[kevin] agree, but all py3 would mean everything is using the same code,
Target here is server-side (hub, web, builder). CLI could still RHEL 6
[dgregor] what do we gain by dropping RHEL 6 support?
There is a fair amount of complexity in the code because of the RHEL 6
[mikem] 1.20 is too soon to drop RHEL 6 support. The answer is "soon".
A good target would likely be summer, 2020 (Koji 1.22 or Koji 1.23)
Start messaging this with the Koji 1.20 release
[tkopecek] should be part of release notes
[ktdreyer] We can also mention that RHEL 6 EOL itself is November 30,
[mikem] The important pieces for Red Hat to continue to support on RHEL
6 are the builder and the client. The kojihub and kojiweb are not as
[mikem] There are ways today that we can extend Koji to call
createrepo_c... let's look at specific use cases
the oldest postgresql version to support -
Will we reorganize our documentation pages?
Yes... looking to refactor https://docs.pagure.org/koji/
Will try to keep old urls working when possible
[Neal] The Fedora wiki pages don't redirect to our docs pages, and they
What do we really want out of koji.build?
https://pagure.io/koji-tools in Fedora
[yzhu] I'm using it, Ken++
[kevin] happy to help review the package
Keepng koji-tools as a separate space for esoteric / one-off scripts,
but things that are essential to koji should be in koji itself
related: koji-wrapper and tag-utils from OpenStack guys
https://github.com/release-depot/tag-utils - cli tools for
https://github.com/release-depot/koji_wrapper - python power user
related: scripts from XCP-ng folks
https://github.com/ktdreyer/koji-ansible and integration tests
How can we coordinate with Brew QE effort?
It's possible to replace almost all of wsgi_publisher.py with Flask
Links from bluejeans chat
Follow up with Brew QE and Ken to see how we can collaborate on Koji
add koji-devel to calendar invite for future community meetings
tkopecek: We can set it as a title in #koji IRC channel +- week before
[kdreyer] that's a good idea
Make sure that koji.build works
3 years, 6 months
py2 sunset and Koji
by Ken Dreyer
All the scripts in https://pagure.io/koji have #!/usr/bin/python2.
There is some code in the Makefiles and koji.spec file that transforms
some (or all?) of these lines to #!/usr/bin/python3.
I would like to reverse this and make #!/usr/bin/python3 the default.
While I am working on this code, I see there are a lot of conditionals
in koji.spec and the Makefiles that have built up over time. It would
be great to drop python2 entirely so that it's easier to read the code
Which parts of Koji must support RHEL 6 (Python 2.6) in Koji's master branch?
3 years, 6 months
koji-ansible modules update for 2019
by Ken Dreyer
Last year I started a project to manage Koji resources with Ansible
modules. The project is https://github.com/ktdreyer/koji-ansible
There are several modules now:
koji_call (in progress at https://github.com/ktdreyer/koji-ansible/pull/64)
I'm using this to manage a couple different Koji instances, and it's
going well so far. Here are some things I've learned along the way.
I have some playbooks that use these modules, and I maintain those
playbooks using Git pull requests. I don't have administrator access
to some of the important Koji instances, so this is a great way for
the administrators to delegate some of the configuration to myself and
other non-admins. In the past there have been some discussions about
increasing the granularity of Koji's ACLs in order to delegate more
configuration to wider groups of users. I think that capturing these
configurations in Ansible is a great way to meet that need without
increasing the complexity of the Koji Hub codebase. In a typical
workflow, I can modify a playbook, run it in "check" mode to verify
that my changes are going to do what I expect, and then I submit the
playbook pull request to the admins to review and merge.
Ansible provides a level of automation that makes large Koji changes
much easier. For some products in Red Hat we have several hundred tags
in Koji that we're managing with Ansible now.
With the level of automation Ansible provides, the accident blast
radius can be large. It's important to have good CI testing here so we
don't destroy things on the hub and fail to notice until it's much too
late. I've found it's tricky to mock or fake Koji's behavior in an
accurate way for anything but the simplest of cases. We do have fakes
and unit tests in koji-ansible for simple test cases, and these are
good for development velocity, but we really need assurance that these
modules will continue to work against real Koji hubs.
To that end, I'm developing an integration test suite for the
koji-ansible project. This integration suite sets up a Koji hub on
Travis CI's environment using Apache, mod_wsgi, SSL authentication,
and a Git clone of Koji's master branch. Once the hub is online, the
test suite runs many different playbooks against the hub, verifying
that the playbooks are doing what I expect. I plan to merge this
integration test suite into master in a week or two.
If you are interested in Koji, please take a look at the modules and
the inline documentation there. This project has taught me a lot about
how Koji's tags, inheritance, external repos, etc fit together, and
I've tried to provide plenty of examples in the module documentation.
3 years, 6 months
Koji 1.19.1 on radar
by Tomas Kopecek
As we've introduced a bug in listPkgs API call, we want to do a quick bug
fix release 1.19.1. I've already created
https://pagure.io/koji/roadmap/1.19.1/ page and koji-1.19-updates git
branch and we're now testing it more properly. We would like to release it
Sorry for problems caused.
Tomas Kopecek <tkopecek(a)redhat.com>
Release Engineering Development, RedHat
3 years, 6 months