diff options
Diffstat (limited to 'doc/architecture/blueprints/runner_scaling/index.md')
| -rw-r--r-- | doc/architecture/blueprints/runner_scaling/index.md | 42 |
1 files changed, 40 insertions, 2 deletions
diff --git a/doc/architecture/blueprints/runner_scaling/index.md b/doc/architecture/blueprints/runner_scaling/index.md index 8e47b5fda8c..174fe191cc7 100644 --- a/doc/architecture/blueprints/runner_scaling/index.md +++ b/doc/architecture/blueprints/runner_scaling/index.md @@ -44,7 +44,7 @@ and the documentation for it has been removed from the official page. This means that the original reason to use Docker Machine is no longer valid too. To keep supporting our customers and the wider community we need to design a -new mechanism for GitLab Runner autoscaling. It not only needs to support +new mechanism for GitLab Runner auto-scaling. It not only needs to support auto-scaling, but it also needs to do that in the way to enable us to build on top of it to improve efficiency, reliability and availability. @@ -144,7 +144,7 @@ on a single machine bring. It is difficult to predict that, so ideally we should build a PoC that will help us to better understand what we can expect from this. -To run this experiement we most likely we will need to build an experimental +To run this experiment we most likely we will need to build an experimental plugin, that not only allows us to schedule running multiple builds on a single machine, but also has a set of comprehensive metrics built into it, to make it easier to understand how it performs. @@ -204,6 +204,44 @@ document, define requirements and score the solution accordingly. This will allow us to choose a solution that will work best for us and the wider community. +### Design principles + +Our goal is to design a GitLab Runner plugin system interface that is flexible +and simple for the wider community to consume. As we cannot build plugins for +all cloud platforms, we want to ensure a low entry barrier for anyone who needs +to develop a plugin. We want to allow everyone to contribute. + +To achieve this goal, we will follow a few critical design principles. These +principles will guide our development process for the new plugin system +abstraction. + +#### General high-level principles + +1. Design the new auto-scaling architecture aiming for having more choices and + flexibility in the future, instead of imposing new constraints. +1. Design the new auto-scaling architecture to experiment with running multiple + jobs in parallel, on a single machine. +1. Design the new provisioning architecture to replace Docker Machine in a way + that the wider community can easily build on top of the new abstractions. + +#### Principles for the new plugin system + +1. Make the entry barrier for writing a new plugin low. +1. Developing a new plugin should be simple and require only basic knowledge of + a programming language and a cloud provider's API. +1. Strive for a balance between the plugin system's simplicity and flexibility. + These are not mutually exclusive. +1. Abstract away as many technical details as possible but do not hide them completely. +1. Build an abstraction that serves our community well but allows us to ship it quickly. +1. Invest in a flexible solution, avoid one-way-door decisions, foster iteration. +1. When in doubts err on the side of making things more simple for the wider community. + +#### The most important technical details + +1. Favor gRPC communication between a plugin and GitLab Runner. +1. Make it possible to version communication interface and support many versions. +1. Make Go a primary language for writing plugins but accept other languages too. + ## Status Status: RFC. |