Portal:Toolforge/Admin/Monthly meeting/2025-04-15
Appearance
Attendees
- Andrew Bogott
- Arturo Borrero
- Bryan David
- Chuck Onwumelu
- David Caro
- Francesco Negri
- Raymond Ndibe
- Sarai Sanchez
- Seyram Komla Sapaty
Agenda
Shift this meeting 0.5h earlier?
- Shift it and request any comments in the invite if needed
k8s upgrade workgroup progress
- 1.29 upgrade finished and working, quite smooth
- No etherpad this time, phabricator + wiki procedure might be enough
- No notes were added to https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Admin/Kubernetes, all the information is in the Phabricator tasks
- 1.30 coming soon (David with Arturo as shadow) (https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Ongoing_Efforts/Toolforge_Upgrade_Workgroup/Upgrades_Overview) it will include the drop of kyverno to use builtin VAPs
- Make sure to create a separate task for the migration from kyverno to VAPs, that will happen after the upgrade to 1.30
OKR updates (Last quarter FY24/25!)
- New push to deploy hypothesis: Prepare and start a beta process for push to deploy
- WIP beta release doc Toolforge push-to-deploy beta
- WE6.3.8/toolforge UI: Wrapped up (Asana report)
- Toolforge UI Scope document – We created a detailed, categorized scope of user needs for Toolforge UI, prioritized by MVP, MVP+, and post-MVP. This living document reflects our product vision, technical constraints, and incorporates feedback from users and subject-matter experts. It serves as a shared reference for planning implementation.
- MVP User Exploration Findings – We conducted sessions with five prospective users to validate the usefulness and usability of our MVP prototype. Their input informed both usability improvements and new feature considerations, which were integrated into the scope document to guide future iterations.
- Toolforge (and toolsbeta) Infrastructure-as-Code using OpenTofu https://phabricator.wikimedia.org/T390056
- More than 100 resources are currently manually configured and are not tracked either in Puppet or Tofu
Toolforge UI/Toolsadmin 2.0 - Intro and MVP prototype walkthrough
- Bryan: Reusing component runtime envs. Assumes that most components are stable and ready for reuse. Maybe “mark as stable/reusable”.
- DC: Read-only version of tool config. We haven’t thought about this much.
- BD: Logging is to also be treated with caution, potential leak of secrets!
- AB: What’s the argument for not adding the functionality into Toolsadmin?
- DC: To be explored. Probably not a blocker. Main concern: fast development. Easier to deploy locally using k8s, instead of trying to directly modify Toolsadmin in prod. Previous dev attempts in Toolsadmin were a bit challenging.
- AB: Agree that local dev container for Striker could make working more optimal, but even if we split TFUI into several components, it’ll still have to solve a lot of the problems that Striker has to currently solve.
- BD: Deployed in production due to LDAP. 100% containerized, Docker composed system
- DC: What services does it install?
- BD: SUL wiki, LDAP wikiBitu, GitLab instance, Keystone instance, Phabricator instance, MariaDB. The complexity of development with Striker has to do with the fact that it’s a “glue” service. Its dev environment used to be tied to MW-Vagrant
- DC: Maybe simplifying/ standardizing would be a good route? Splitting API and abstracting/decoupling from app could simplify things.
- FN: Discussion about ideal architecture of TFUI. 3 options:
1) Put everything in Toolsadmin; 2) Creating new app that relies on Toolsadmin (splitting the code in backend glue and the rest): 3) Build everything from scratch and deprecate Toolsadmin. Bryan and Taavi should be contacted as maintainers of Striker and have a prominent role in the decision-making process.
- Technically Striker now belongs to WMCS
- FN: Product decision of what are we trying to build in relation to Striker needs to be made, even before conceptualizing design.
Action items
Dcaro: to create a monthly toolforge update report + email