*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
- https://pagure.io/koji/roadmap/1.19/
- 51 closed issues
- about three months since 1.18 release
- https://docs.pagure.org/koji/release_notes_1.19/
- Koji 1.19.1 (bugfix release)
- https://pagure.io/koji/roadmap/1.19.1/
- https://docs.pagure.org/koji/release_notes_1.19.1/
- Feedback or retrospective
- Neal hasn't had a chance to try it out yet but is glad about the
responsiveness and cadence of releases.
- Koji1.20
- Proposed issues so far - https://pagure.io/koji/roadmap/1.20/
- timeframe:
- code freeze: start of Jan.
- release plan by the end of Jan.
- MBS plans progress
- still in progress, Brew start from Q4
- Others
-
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
big jump.
-
[kevin] agree, but all py3 would mean everything is using the same code,
but yeah.
-
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
support
-
[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,
2020, https://access.redhat.com/support/policy/updates/errata
-
[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
important.
-
[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 -
https://pagure.io/koji/issue/1754
-
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
should
-
What do we really want out of koji.build?
-
https://pagure.io/koji-tools in Fedora
-
koji-ssl-admin
-
[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
managing/viewing/tag maintenance
-
https://github.com/release-depot/koji_wrapper - python power user
scripting library
-
related: scripts from XCP-ng folks
-
https://github.com/xcp-ng/xcp/tree/master/scripts/koji
-
https://github.com/ktdreyer/koji-ansible and integration tests
-
How can we coordinate with Brew QE effort?
-
kojiweb future
-
It's possible to replace almost all of wsgi_publisher.py with Flask
-
Links from bluejeans chat
-
https://pagure.io/fm-orchestrator/issue/1241
*Actions Items*
-
dgregor
-
Follow up with Brew QE and Ken to see how we can collaborate on Koji
integration testing
-
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
Thanks,
Yuli
Dear, All
Next Koji community meeting is scheduled this Wed. Let’s talk the feedback
on Koji1.19, Koji roadmap and anything else you concern.
Here is *meeting reminder* in case someone didn't get or note
the meeting invitation:
*Meeting docs: *https://pad.mozilla.org/p/KojiNov2019
*Meeting Time:* Nov 20 2019 10:00-11:00AM US/ET
*Where: * https://bluejeans.com/1265288041
*Proposed Agenda:*
- Koji update:
- Koji 1.19/koji1.19.1 released
- https://pagure.io/koji/roadmap/1.19/
- Feedback or retrospective
- Koji1.20
- Proposed issues so far - https://pagure.io/koji/roadmap/1.20/
- MBS plans progress
- Others
Feel free to add more topics you want to talk. See you this Wed.
Thanks,
Yuli
Hi folks,
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
and contribute.
Which parts of Koji must support RHEL 6 (Python 2.6) in Koji's master branch?
- Ken
Hi folks,
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_archivetype
koji_btype
koji_call (in progress at https://github.com/ktdreyer/koji-ansible/pull/64)
koji_cg
koji_external_repo
koji_host
koji_tag_inheritance
koji_tag
koji_target
koji_user
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.
- Ken
Koji 1.19.1 is out. Thanks to everyone who contributed!
You can read the release notes here:
https://docs.pagure.org/koji/release_notes_1.19.1/
This was a small bugfix release to fix three significant bugs:
* Fix permissions to check tag/target/host permissions
* Fix hub reporting of incorrect ownership data
* Fix issue with listing users with old versions of Postgres
If you have deployed 1.19 please upgrade to this version ASAP as these
were breaking bugs.
You can view the 1.19.1 roadmap at https://pagure.io/koji/roadmap/1.19.1/
For the current roadmap, see https://pagure.io/koji/roadmap
You can download this and other releases at https://pagure.io/koji/releases
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
in ~week.
Sorry for problems caused.
--
Tomas Kopecek <tkopecek(a)redhat.com>
Release Engineering Development, RedHat