Wikimedia Cloud Services team/EnhancementProposals/Decision record T325382 Choose a lang for the toolforge build service API

From Wikitech

NOTE: Follows the discussion to move to an API design or not here Template:T326136

Origin task: phab:T325382

Date of the decision: 2023-01-17

People in the decision meeting (alphabetical order):


Decision taken

Option 1.

Rationale

We decided to proceed with Option 1, without consensus but majority of the votes.


Problem

We have decided to create an API for the toolforge build service, we need to choose a language for it.

Constraints and risks

  • We have considerable python knowledge in the team
  • We have little golang knowledge in the team, this might increase the time to build it
  • The k8s ecosystem is built around golang, this might ease the maintenance if golang is chosen
  • Some of our components are written in golang (all the admission/validation hooks), this might help maintaining those if golang is chosen
  • Toolforge Job service is written in python, and has a similar design, this might help reusing and or sharing knowledge if python is chosen
  • There's no strong investment either way for toolforge components, though there's no trials of API design with golang, this could give some experience on both languages before (if) deciding to converge all components to one lang/tooling

NOTE: Full list of libraries here phab:T325382#8488267

Options

Option 1

Implementing it in golang.

Pros:

  • Golang k8s libraries are the only ones manually developed by upstream, and the main upstream libraries that they design for, they have extensive concurrency support, they are typed, and have testing helpers, all the others are ether automatically generated or not maintained by upstream.
  • We gain experience with golang component design
  • We gain experience with golang as a whole (and better support current golang components)

Cons:

  • Some initial investment is needed to develop the API

Option 2

Implementing it in python.


Pros:

  • Python knowledge in the team makes it simple to use best practices
  • We can reuse some of the code already existing for toolforge-jobs-framework

Cons:

  • The python k8s libs are autogenerated from the golang ones, don't have builtin async support (they have a limited concurrency API, not using the builtin python one), type hints, or testing helpers.
Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T325382_Choose_a_lang_for_the_toolforge_build_service_API&oldid=2123141"