Change Details

**NOTE:** this depends on {{T326136}}, the discussion about using API or not will happen there. == 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, so should be quicker to use * We have little golang knowledge in the team, so should take longer * The k8s ecosystem is built around golang * Some of our components are written in golang (all the admission/validation hooks) * Toolforge Job service is written in python ... To be filled up == Decision record == In progress https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T325382_Choose_a_lang_for_the_toolforge_build_service_API == Options == === Option 1 === Implementing it in golang. To overcome the lack of golang experience and knowledge, we can start by converting the toolforge cli to golang. Pros: * Unblocks many features * Golang k8s libraries are very well maintained and easy to use and test * We gain experience with golang by improving the toolforge cli project Cons: * Some initial investment is needed to develop the API === Option 2 === Implementing it in golang without using toolforge-cli to learn about the ecosystem. Pros: * Golang k8s libraries are very well maintained and easy to use and test Cons: * Lack of golang experience might delay and introduce extra issues in the process. === Option 3 === 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. Implementing it in python. Pros: * Python knowledge in the team makes it simple to use best practices Cons: * The python k8s libs are not as well maintained, harder to test and develop with

**NOTE:** Follows the discussion to move to an API design or not here {{T326136}} == 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 == Decision record == In progress https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T325382_Choose_a_lang_for_the_toolforge_build_service_API == Options == === Option 1 === Implementing it in golang. Pros: * Golang k8s libraries are the only and main libraries, they have extensive concurrency support, they are typed, and have testing helpers. * 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 === === Option 3 === 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.

**NOTE:** this depends on {{T326136}},Follows the discussion about usingto move to an API design or not will happen there.here {{T326136}} == 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, so should be quicker to use * We have little golang knowledge in the team, so should take longerthis 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, To be filled upthis could give some experience on both languages before (if) deciding to converge all components to one lang/tooling == Decision record == In progress https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T325382_Choose_a_lang_for_the_toolforge_build_service_API == Options == === Option 1 === Implementing it in golang. To overcome the lack of golang experience and knowledge, we can start by converting the toolforge cli to golang. Pros: * Unblocks many featuresGolang k8s libraries are the only and main libraries, they have extensive concurrency support, they are typed, and have testing helpers. * Golang k8s libraries are very well maintained and easy to use and test* We gain experience with golang component design * We gain experience with golang by improving the toolforge cli projectas a whole (and better support current golang components) Cons: * Some initial investment is needed to develop the API === Option 2 === Implementing it in golang without using toolforge-cli to learn about the ecosystem. Pros: * Golang k8s libraries are very well maintained and easy to use and test Cons: * Lack of golang experience might delay and introduce extra issues in the process. === Option 3 === 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. 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 not as well maintainedautogenerated from the golang ones, don't have builtin async support (they have a limited concurrency API, not using the builtin python one), harder totype hints, or test and develop with ing helpers.