I’d love to join but I’m already in another session at this time 😔

In T336055#8829621, @Lucas_Werkmeister_WMDE wrote:

I’d love to join but I’m already in another session at this time 😔

I wouldn't mind doing an informal preview at another time, for you and anyone else who can't join this session.

Etherpad for this session: https://etherpad.wikimedia.org/p/Toolforge_Build_Service_beta_preview

Notes from session:

Toolforge Build Service beta preview

Date & time: Sunday, May 21st at 9:30 am EEST / 6:30 am UTC

Relevant links

• Phabricator task: https://phabricator.wikimedia.org/T336055
• Build Service documentation: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Build_Service
• push to deploy proposal: https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Toolforge_push_to_deploy
• https://github.com/blancadesal/fastapi-toolforge-blueprint

Participants (~10)

Notes

• build packs move Toolforge towards a “platform as a service” experience and also away from grid engine
• build packs were launched by Heroku, now a CNCF standard: a way to package source code into a container runnable on various platforms
• current status: a Python tool can be completely deployed as a build pack, and some other languages are supported too; but no support for multi-runtime images yet
• Python tools can now implement ASGI (previously only WSGI was supported) – fulfills one of the wishes from the community wishlist survey 2023 \o/
• code must be hosted publicly now (images are built from a public Git repository)
• Python code must have requirements.txt now (the venv is built based on the source code, not manually by the tool maintainer)
• a few other ways to specify dependencies might also work (setup.py? pyproject.toml?), not sure
• the Procfile specifies how to run the tool (“web:”) and/or possibly other commands (such as a script to run before the process launches, e.g. a migration)
• the other commands can also be implemented in a Bash script which is specified by the Procfile
• currently, the web command has to listen on port 8000
• the functionality is already available on Toolforge – not generally announced yet, but anyone can try it out if they want
• SSH into Toolforge, become tool account, use the toolforge CLI command (e.g. toolforge --help)
• toolforge build start https://github.com/blancadesal/fastapi-toolforge-blueprint.git to launch the build pack pipeline
• currently, there’s no permanent association between the tool identity and the Git URL; might be added later (build from the repo specified in toolinfo / tooladmin by default?)
• image ends up in https://tools-harbor.wmcloud.org/harbor/projects (web interface only accessible to admins)
• toolforge build show to see the status of the build, toolforge build logs to see build logs
• the image can be run locally:

docker run -p 8000:8000 tools-harbor.wmcloud.org/tool-TOOLNAME/tool-TOOLNAME:latest

• toolforge webservice buildservice start to start the webservice using the new buildservice type
• toolforge webservice is currently an alias to webservice (identical functionality); toolforge jobs also works as an alias for toolforge-jobs; trying to consolidate all Toolforge functionality under this prefix

Pt. 2

• Goals - improve the user experience of ToolForge, to be a Paas platform such as Heroku, etc, so it can be easier for users to configure and use. In the future, evolving the platform to be something like these other "Platform as a Service" services, but for open source projects.

• Build packs were invented by Heroku, but became a cloud standard. Today we have an ecosystem built around build packs. They are a way to take source code packaged into a container and ported into any platform that supports build packs.

• This is a beta/alpha preview to introduce the build service.

• You need to have your code hosted on an open-source platform to use it. You can go to toolfoge and tell it to build it from an open repo. Now you can use gunicorn on your project on your requirements.txt. You need this file now since you're not the one creating your environment since the service creates it for you.

• With a Procfile, you can specify the environment you want your app to run. You can also execute your own bash script if you want to customize your build. It allows various levels of flexibility. You don't need a specific folder structure - like with a src folder - you can just tell in the Procfile how to execute your app.

• Supporting ASGI on toolforge was an item on the community wishlist[1].
• Feel free to provide feedback on the session task. [2]

• New ToolForge CLI - it unifies services under one new CLI.

Examples
To build a new project:
toolforge build start [link to repo]

• You can specify a dev branch, for instance. In the future, you will be able to do this in a web UI. For now, the CLI is the way to build it.
  
  You get error messages and logs in the CLI - for now, build logs require admin access, it is being worked on by the team.
  
  Start service: toolforge webservice builservice start

• Now we have a 1GB limitation on the server, if you exceed your disk space you'll get an error, error message is still under improvement for this error.

• It is possible to set some preferences manually from the Harbor interface.

• For anything outside of your container that you need to have access to, you'll need to leave out your home container folder.

• Your tool can cd into any directory, it won't cause a conflict with the buildpack environment.

• Config variables are being worked on, if you deploy in Heroku you can config them directly, for example, but for now, you can pull them in from a file into your code to config them in ToolForge.

• A page/email/blog post to announce news to users an intermediate steps will be available soon. For now you can watch the phab task and wikitech page [3].

• New users can have a rough start using the tool, but more experienced users should be fine getting started.

• ToolForge can be hard to navigate to users that are getting started, can be hard to maintain tools

Questions/comments

• When you deploy from buildpack you don't need the source code in a specif directory? No

• How far away is the secret service?

Setting the env variables more easily is on the way, for now, you have to enter variables/secrets on the CLI manually.

Read credentials from a specific file is still not available. It could be nice to run tools locally, reading from a previously existing file, and also use it in the service.

• Toolforge webservice commands are aliases, we're trying to consolidate interfaces in the command to be more elegant.

• We're trying to accommodate people using kubernetes to be more welcoming to all kinds of projects.

• ML models and tools are out of the question for this service since tools like pytorch can create large projects right away, which is not supported right now. we're not sure if we're limiting build right away like heroku

Something like an LLM as a service would be something extremely resource-consuming.
We're not LLM specialists, so it would require guidance on how to build a service that supports this.

[1]https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Bots_and_gadgets/Support_ASGI_on_Toolforge
[1] https://phabricator.wikimedia.org/T296729

[2] https://phabricator.wikimedia.org/T336055

[3] https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Toolforge_push_to_deploy