Portal:Toolforge/Admin/Monthly meeting/2023-10-03
Agenda:
- Toolforge + Developer Account Creation. Can we streamline this? Can we remove the moderation from Toolforge? phab:T346384 is for the docs work, but any process/infra improvements will help make the docs simpler.
- Deploy right after merging, if it's not ready for deployment it's probably not ready to get merged. Specially avoid merging and not deploying (piling up changes).
- Toolforge bulid service workgroup widening scope to the whole of toolforge.
- Toolforge re-design decision request status and next steps phab:T346153.
- Toolforge build service open beta date proposal phab:T335249.
- Toolforge lima-kilo status, challenges, opportunities
the harbor case what about vagrant adoption: licensing? are we ready to declare lima-kilo the canonical development environment setup tool? Pre-built Pywikibot image (phab:T249787) https://gitlab.wikimedia.org/taavi/pywikibot-script-buildservice/-/commits/stable
Notes
- Action items from the previous meeting - send second round of invites for the build service - Done
Different topics for account creation
Do we want users to do things in toolforge or just tools?
Do we want to skip moderation for tool account creation? If so how?
Bd: In the past the main concern was misbehavior of users
Bd: Now we have the ability to delete a tool
Bd: We have the ability to simply lock a developer account and that not only stops logging in but has hooks to stop running processes (maybe look if k8s also or only grid)
Ab: I agree with that, I have a question about disabling a developer account, what's the mechanism? Just ldap?
Bd: yep blocking on wikitech is the easiest but it's all ldap underneath
Ab: I'm comfortable with us having a self-serve process within toolforge, I'm concern that having something in ldap might confuse someone else into thinking that they have more right
Bd: self-service developer accounts has been open in wikitech for a long time already
Ns: how do we find bad actors in toolforge? What metrics we have to find abusive account/bad actors?
Tv: yesterday I did a regular check of running processes on the bastion, I think that the best way forward might be to create a decision record and continue the discussion there
Ns: it seems that there's a consensus though on this being doable
NS: The second part is can we simplify the text on https://wikitech.wikimedia.org/wiki/Help:Toolforge/Quickstart#Get_access aka going through registration on toolsadmin vs not.
Fn: about the second part/toolforge account creation can we simplify the flows, specially now that we have a new account management tool
Bd: historically we had a long list of instructions that made you jump through many websites to end up getting a toolforge account, it seems that you are suggesting a similar thing though now we have a smaller number of sites to jump through, so that might be possible, but it's still not a very nice flow
After the discussion Bryan found historical notes related to these questions on https://phabricator.wikimedia.org/T128158#2128397 and https://phabricator.wikimedia.org/T144710
Deploy right after merging
DC: Merging a commit, you should deploy after to avoid piling up commits. PSA, please deploy after you merge and test in toolsbeta and tools to avoid confusion Toolforge build service workgroup widening scope to the whole of toolforge.
DC: Want to widen the scope of the toolforge build service to include everyone and all of toolforge. Meet as a group every 2 weeks, decide on what to work on. Want to work more cohesively with each other. See workboard https://phabricator.wikimedia.org/project/view/6763/
TV: Two meetings now for these groups? Can we fix?
DC: One is called check-in, the other toolforge workgroup meeting. Can fix.
Toolforge re-design decision request
DC: Did project catalyst change anything?
SS: Decided catalyst won’t be on toolforge, so the decision can continue
SS: Will move forward and set dates. No one has voted yet, asking for people to vote now that discussion has happened
Toolforge build service open beta
DC: Second round of invites sent already. No feedback yet. Proposing opening the beta to everyone. Next Monday work? Plan to update wikitech and send announcement
NS: What should we do with grid users?
TV: Let’s see what happens before pushing harder. Put on next month agenda
TV: Is anything else needed or is TBS ready?
DC: It’s ready for beta. Maybe not yet for production, missing some monitoring I want. Triggering when you push and deploying when you finish isn’t in place yet. Some flows are less tested. Like static files.. Everything present is stable and working. Would like more feedback.
SS: Hackathon in Singapore. Some awareness, but unaware about new features. Seems like a larger announcement is warranted. Need to really push on what’s possible now.
DC: I’ll work with Komla to do announcement next week
Toolforge lima-kilo status
ABG: Discuss future of lima-kilo. Recently added support for harbor. This proved difficult, but it’s working. Working with toolforge is complex, and so is the dev environment. Would suggest making lima-kilo the official dev environment for toolforge, but up to others to decide. Vagrant was seen as a potential solution, but licensing concerns (hashicorp) exist for it. Other virt options exist to consider. Staying neutral on deciding
DC: lima-kilo works well to setup environment for testing complex workflows. But could test single components more simply. It’s useful. Vagrant adoption started before licensing changes. Having VM is helping a lot in reducing problems with differing setups. Right now, using lima-kilo with VM personally.
FN: Some of the hacks/difficulties across environments could be fixed with tweaks for compatibility. If debian VM is desired for everyone, we can do it without vagrant/ Can publish standard VM image and allow others to decide how to run.
BD: What’s a standard image?
FN: Something that random virtualization software can load
TV: You mean a base debian install?
FN: I meant an image that also had state, but could do minimal debian
TV: Simplest option would be just focusing on running debian, it can install needed things
DC: If decide on debian install, can more freely use ansible without cleaning up, etc
BD: VirtualBox is not universally available anymore because it does not support silicon Macs.
TV: Anyone planning on implementing this?
DC: Maybe on the side
Pre-built Pywikibot image
TV: Experimenting today. Build an image with pywikibot scripts, using envvars to build. Important since lots of tools use this workflow. Had to hack pywikibot to remove check for permissions. If we want to make this official, need to think about hosting and maintaining. Also some changes to jobs framework to assist this. Would enable grid migrations
DC: So build an image and share, or allow people using buildpacks to use it
TV: Have a pre-built image for someone who doesn’t have custom changes and just wants to run pywikibot
DC: You can use any image
TV: Is that the workflow we want though?
AB: what is the difference between pywikibot image and user adding pywikibot as a dependency in buildpack?
TV: Custom image could offer zero config. As a dependency it will require you to build image and have a git repo, etc. Useful for someone wanting to run something pywikibot supports without changes
Action items
- Dcaro and komla to open the beta next week
- Dcaro to start working on lima-kilo inside-vm move