WIP: worker pool #62
WIP: worker pool #62
Conversation
evanchaoli
force-pushed
the
worker-pool
branch
4 times, most recently
from
e52fe9e
to
781ddee
Compare
| This is a useful mechanism to isolate some teams' workload or to provide | ||
| dedicate workers to some teams. |
There was a problem hiding this comment.
Maybe it's just that I run a (I guess, relatively) small Concourse instance, but I'm struggling to understand the underlying motivation here.
A core tenet of Concourse is avoiding worker state, with tags being a compromise to allow for e.g. hardened network architectures. Why do teams care about isolating their workload in the first place? How does one team's workload affect another team's workload? If it's to ensure worker availability for their projects, doesn't it make more sense to work on a feature like auto-scaling workers (i.e. "grow the pie") rather than a feature to protect and hoard "precious" workers (i.e. "divide the pie")?
If an organization really wants to provide a high level of isolation, why not set up isolated Concourse instances? Why only isolated Concourse worker pools?
| # Summary | ||
|
|
||
| This proposal outlines the support for worker pool. A worker pool is a group | ||
| of Concourse workers, that can be associated with one or multiple teams. |
There was a problem hiding this comment.
For what it's worth, when I originally heard of "worker pools", I was thinking more along the lines of allowing different Concourse installations to coordinate with each other to access a common pool of workers, which would make it much easier to launch new Concourse installations for different teams by giving them access to some workers already by default and not have to set up workers separately in order to get started.
Signed-off-by: Chao Li <chaol@vmware.com>
|
@vito Thanks for your early review that makes my work easier. |
|
@muntac to review |
Signed-off-by: Chao Li chaol@vmware.com