Test-infra: Add a prow controller manager binary
What would you like to be added:
A prow controller manager binary that contains:
- Sinker
- Plank
- Crier
- Jenkins opreator
Probably more in the future
Why is this needed:
The current design of "one binary per controller" has a set of drawbacks:
- It makes prow hard to debug for ppl that are not intimatedly familiar with its architecture
- It makes prow hard to setup, because a total of a billion flags has to be set properly
- It creates a needless amount of overhead on the apiserver due to zero cache sharing
- It increases the overhead for adding something to Prow
A sample of "Weird things we did because overhead of a new component is too high": The abortDuplicates functionality is in a library and imported by multiple agent implementations instead of having one controller that sets unneeded ProwJobs to aborted via a spec field and then have all the agents abort the test workloads based on that.
/area prow
alvaroaleman
All 12 comments
Wouldn't it be better if that was handled similar to how hook plugins are handled right now, so that the proposed components would be plugins of a prow-controller-manager.
Thinking of that approach since not everyone is using e.g. crier, jenkins operator. Plank and sinker could be enabled by default and if someone wants more, enable more?
tehcyx
on 31 Mar 2020
Wouldn't it be better if that was handled similar to how hook plugins are handled right now, so that the proposed components would be plugins of a prow-controller-manager.
Thinking of that approach since not everyone is using e.g. crier, jenkins operator. Plank and sinker could be enabled by default and if someone wants more, enable more?
Generally, adding flags to enable/disable certain controllers could make sense. IMHO all of the mentioned controllers should be enabled, they will not do anything if you don't use them.
alvaroaleman
on 31 Mar 2020
Hook and deck have different availability requirements and therefore should remain separate. Merging the other stuff -- how about horologium? -- makes sense.
fejta
on 31 Mar 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 29 Jun 2020
/remove-lifecycle-stale
This actually exists already at https://github.com/kubernetes/test-infra/blob/3c8c05e6db807a2edb26f354cfd069fea3e1080d/config/prow/experimental/controller_manager.yaml and currently contains the PlankV2 implementation
alvaroaleman
on 29 Jun 2020
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
fejta-bot
on 29 Jul 2020
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
fejta-bot
on 29 Aug 2020
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
k8s-ci-robot
on 29 Aug 2020
/reopen
/lifecycle active
alvaroaleman
on 2 Sep 2020
@alvaroaleman: Reopened this issue.
In response to this:
/reopen
/lifecycle active
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
k8s-ci-robot
on 2 Sep 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 1 Dec 2020
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
fejta-bot
on 31 Dec 2020
Related issues
Aisuko
路
3Comments
cjwagner
路
3Comments
zacharysarah
路
3Comments
BenTheElder
路
4Comments
xiangpengzhao
路
3Comments
Most helpful comment
Hook and deck have different availability requirements and therefore should remain separate. Merging the other stuff -- how about horologium? -- makes sense.