Migration to Debian style releases via the APT ecosystem

[isi-pchandler (Phil Chandler)]

Just jotting down some take-aways from the follow up zoom call with the team:

Some changes to the proposal based on feedback and discussion

• unstable should be the foyer for package promotion to other release channels like testing etc.

Next steps:

0. Double check Nexus’ support for RPM package management
   • Primarily to get a preview of the future cost of supporting that ecosystem
1. Stand up an “alpha” draft backoffice infrastructure for Nexus plus a dedicated GitLab runner (for uploads to nexus) on Digital Ocean
   • Should be infrastructure-as-code, driven from “source” in a GitLab repo
   • First attempt will be using a k8s based deployment and DO’s managed k8s
2. Create an “alpha” draft of a toolkit for package builds and uploads that package maintainers can use in their respective package’s source repositories
   • Host it in its “source” in its own GitLab repo
   • Some of the toolkit will be a mix of
     • gitlab-cicd.yml dot files that can be included into other ci/cd yaml configs to setup custom steps etc.
     • docker images with packaging tooling baked in, for local package builds as well as identical workflows within ci/cd jobs
     • A selection of tailored packaging and package upload tools/scripts
3. Create a strawman package project that uses the above, and acts as a living example of the “alpha” edition of the methodology
4. A docs-as-code repo describing the “alpha” edition of the release management / engineering “architecture”, conventions, and assumptions. user guide / design guide to the release engineering
5. Invite package maintainers to start using this alpha ecosystem in parallel with the legacy release management approaches, and evolve the alpha ecosystem based on the feedback from those experiences
   • As part of this, look at how to reduce some the ergonomic headaches with things like cross-project integration testing
   • Also how/where to wire in automated integration/system test harnesses

[isi-pchandler (Phil Chandler)]

Some updates:

• Nexus is on the back burner due to its heavyweight footprint and our Digital Ocean budget
  • Have a working k8s prototype for it (archived here )
• In lieu of Nexus, will look at alternate workflows using reprepro or aptly
  • source project will live here (currently just a stub)
  • Was going to evaluate aptly first, but putting it on backburner due to complaints about it being unmaintained
  • Instead, I’ll look at reprepro first

[isi-pchandler (Phil Chandler)]

A working draft of a reprepro-based solution is fleshed out and ready for review and refinement.

Please see this GitLab hosted wiki for the current documentation, especially the Overview and Adoption pages.

Its a very early attempt at documenting the practices, plumbing, and rollout plan. I’m looking for feedback and review to help fine tune things to strike the best compromise between developer-side ergonomics and the requirements of the multiverse release model.

For complex todo items based on feedback, I will be making gitlab issues in that documentation project.