testkube icon indicating copy to clipboard operation
testkube copied to clipboard

feat: Multi agent

Open exu opened this issue 1 year ago • 3 comments

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

exu avatar Sep 11 '24 10:09 exu

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)
  • runnerAffinity could be defined on any level (globally, per workflow, per execution)

rangoo94 avatar Sep 26 '24 14:09 rangoo94

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)
  • runnerAffinity could 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.

exu avatar Sep 27 '24 06:09 exu

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)

rangoo94 avatar Sep 27 '24 13:09 rangoo94