Wikimedia Cloud Services team/EnhancementProposals/Decision record T326136 Toolforge build service to move to an API design
Origin task: phab:T326136
Date of the decision: 2023-02-06
No decision meeting needed, people commenting in the task:
- User:Arturo_Borrero_Gonzalez
- User:David_Caro
- User:FNegri
- User:Nskaggs
- Slavina Stefanova User:Slst2020
Decision taken
Option 2. Moving to an http API design
Problem
The current design relying on the cli to interact with k8s makes it hard to implement certain very desirable features like:
- Users to see build logs
- Quotas for builds
- Multiple interfaces (Potential UI + cli)
- Local cli execution (outside of the bastions)
Note that the scope of this decision is only about moving to an API design, the details of which language, etc. will be discussed later on in phab:T325382 if we decide to go for it.
Constraints and risks
- Developing certain features (starting with the above ones) will become harder and harder
- Duplication of code implementing business processes will become a must for multiple interfaces (ex. cli, web, ...)
Decision record
Option 2 was chosen, move to an API design.
Options
Option 1
Leave it like it is now.
Pros:
- No immediate effort needed
Cons:
- Increased and potential blockers implementing future features (see the list in the description)
- Increased maintenance for more than one client platform
Option 2
Create an API living in k8s that will take care of interacting with the k8s service, and expose all the needed functionality to the clients through an http API.
Pros:
- Unblocks many features
- Eases the development and maintenance of different clients
Cons:
- Some initial investment is needed to develop the API
NOTE: This discussion started at phab:T325382