feat: Multi agent
Pull request description
Checklist (choose whats happened)
- [ ] breaking change! (describe)
- [ ] tested locally
- [ ] tested on cluster
- [ ] added new dependencies
- [ ] updated the docs
- [ ] added a test
Breaking changes
Changes
Fixes
Considering that in this PR the runner IDs are not dynamic (but needs to be pre-created), either:
- There should be no Runner ID thing, but rather separate Agent Keys for each of them
- The Runner ID should be completely dynamic (and informal + not unique)
On the other hand, the best solution is to avoid runner IDs at all, and have runner tags instead (like K8S nodeAffinity -> Testkube runnerAffinity). It would work great:
- simple,
- Kubernetes-like,
- fully customizable,
- scalable (as runners could be created on demand too)
-
runnerAffinitycould be defined on any level (globally, per workflow, per execution)
Considering that in this PR the runner IDs are not dynamic (but needs to be pre-created), either:
- There should be no Runner ID thing, but rather separate Agent Keys for each of them
- The Runner ID should be completely dynamic (and informal + not unique)
On the other hand, the best solution is to avoid runner IDs at all, and have runner tags instead (like K8S
nodeAffinity-> TestkuberunnerAffinity). It would work great:
- simple,
- Kubernetes-like,
- fully customizable,
- scalable (as runners could be created on demand too)
runnerAffinitycould be defined on any level (globally, per workflow, per execution)
But you need some kind of ID here (whatever we name it) to e.g. schedule against it - I'm not sure if we really should follow Kubernetes naming here at all. These points are both valid for IDs and tags like in affinity.
I agree about separate keys - if we want to decouple runners from environments - it'll be next thing to do for sure.
But you need some kind of ID here (whatever we name it) to e.g. schedule against it
- You only need to target a tag, not ID - if someone wants to have actually unique way to identify them, simply there may be some tag unique 🙂
- IDs may be required, but not in the way that User needs to pass them and register in the Cloud. They may only be useful to pull the already started execution information, or control it (pause, resume, abort), It would be enough to provide such ID on the Agent (or rather Worker/Runner) only then (and associate to i.e. execution)