EPEL-8 Production Layout
- EPEL-8 will have a multi-phase roll-out into production.
- EPEL-8.0 will build using existing grobisplitter in order to use a ‘flattened’ build system without modules.
- EPEL-8.1 will start in staging without grobisplitter and using default modules via mock.
- The staging work will allow for continual development changes in koji, ‘ursa-prime’, and MBS functionality to work without breaking Fedora 31 or initial EPEL-8.0 builds.
- EPEL-8.1 will look to be ready by November 2019 after Fedora 31 around the time that RHEL-8.1 may release (if it uses a 6 month cadence.)
- 8.0 will be a ‘minimal viability’. Due to un-shipped development libraries and the lack of building replacement modules, not all packages will be able to build. Instead only non-modular RPMs which can rely on only ‘default’ modules will work. Packages must also only rely on what is shipped in RHEL-8.0 BaseOS/AppStream/CodeReadyBuilder channels versus any ‘unshipped -devel’ packages.
- 8.1 will add on ‘minimal modularity’. Instead of using a flattened build system, we will look at updating koji to have basic knowledge of modularity, use a tool to tag in packages from modules as needed, and possibly add in the Module Build System (MBS) in order to ship modules.
- 8.2 will finish adding in the Module Build System and will enable gating and CI into the workflow so that packages can tested faster.
Problems with koji, modules and mock
/etc/mock/foo.cfgwhich will turn on and off modules as needed so that you can enable the
virt-develmodule so that packages like
javapackages-localare available. However koji does not allow this control per channel because it is meant to completely control what packages are brought into a buildroot. Every build records what packages were used to build an artifact and koji will create a special mock config file to pull in those items. This allows for a high level of auditability and confirmation that the package stored is the package built, and that what was built used certain things.
epoch-version-release-timestampso that only the newest version is in. (If the timestamp is the same, it tends to refuse to use both packages).
mergerepowhich allows for dnf to make a choice on which packages to use between repositories. This allows for mock’s dnf to pull in modules without the repositories having been mangled or ‘flattened’ as with grobisplitter. However, it is not a complete story. For DNF to know which modules to pull in it needs to set an environment variable for the platform (for fedora releases it is something like f30 and for RHEL it is el8). Koji doesn’t know how to do this so the solution would be to set it in the build systems
/etc/mock/site-defaults.cfgbut that would affect all builds and would cause problems for building Fedora on the same build system.
|Start Date||End Date||Work Planned||Party Involved|
|2019-07-01||2019-07-05||Lessons Learned||Smoogen, Mohan|
|2019-07-08||2019-07-12||Release Build work||Mohan, Fenzi|
|2019-07-08||2019-07-12||Call for packages||Smoogen|
|2019-07-15||2019-07-19||Initial branching||Mohan, Dawson|
|2019-07-22||2019-07-31||First branch/test||Dawson, et al|
|2019-08-01||2019-08-01||EPEL-8.0 GA||EPEL Steering Committee|
|2019-08-01||2019-08-08||Lessons Learned||Smoogen, et al|
|2019-08-01||2019-08-08||Revise documentation||Smoogen, et al|
|2019-09-01||2019-09-01||Bodhi gating turned on||Mohan|
EPEL-8.0 Production Breakout
- Lessons Learned. Document the steps and lessons learned from the previous time frame. Because previous EPEL spin-ups have been done multiple years apart, what was known is forgotten and has to be relearned. By capturing it, we hope that EPEL-9 does not take as long.
- Documentation. Write documents on what was done to set up the environment and what is expected in the next section (how to branch to EPEL-8, how to build with EPEL-8, dealing with unshipped packages, updated FAQ)
- Call for Packages This will be going over the steps that packagers need to follow to get packages branched to EPEL-8.
- Release Build Work. This is setting up the builders and environment in production. Most of the steps should be repeats of what was done in staging with additional work done in bodhi to have signing and composes work
- Initial Branching. This where the first set of packages are needed to be branched and built for EPEL-8: epel-release, epel-rpm-macros, fedpkg-minimal, fedpkg (and all the things needed for it).
- First Branch Going over the various tickets for EPEL-8 packages, a reasonable sample will be branched. Work will be done with the packagers on problems they find. This will continue as needed.
- EPEL-8.0 GA Branching can follow normal processes to get done.
- Lessons Learned. Go over problems and feed into other groups backlogs.
- Documentation Update previous documents and add any that were found to be needed.
|Start Date||End Date||Work Planned||Party Involved|
|2019-07-01||2019-07-05||Lessons Learned||Fenzi, Contyk, et al|
|2019-07||???||Groom Koji changes needed||???|
|2019-07||???||Write/Test Koji changes needed||???|
|2019-07||???||Non-modular RPM in staging||???|
|2019-07||???||MBS in staging||???|
|2019-08?||???||Implement Koji changes?||???|
|2019-08?||???||Implement bodhi compose in staging?||???|
|2019-09?||???||Close off 8.1 beta||???|
|2019-09?||???||Begin changes in prod?||???|
|2019-10?||???||Open module builds in EPEL||???|
|2019-11?||???||EPEL-8.1 GA||EPEL Steering Committee|