request: remove vendoring from this repo

[jaypipes]

Area

• [X] Scheduler
• [X] Controller
• [ ] Helm Chart
• [ ] Documents

Other components

No response

What happened?

We mirror the scheduler-plugins repository into our private build servers in order to comply with our secure software supply chain policies. There is governance and vulnerability automation that scans the repository for CVEs and licensing issues. Unfortunately, this repository uses Go vendoring which means two things:

1. When we pull in new upstream code, we need to pull in sometimes millions of lines of code (most of which is in the vendor/ folder) making it difficult if not impossible to know what outside of the dependencies has changed.
2. Our governance and CVE automation scans all the vendored code and alerts on everything it finds, and we need to manually change the go.mod file to include "fixed" versions of dependencies (many times there isn't, frankly, a usable version of a dependency because of incompatible 0-series versions, but we still have to struggle through trying to update the dependency anyway)

If this repo didn't use vendoring, our life would be a whole lot easier because a) there'd be a whole lot less code in the repository and Git commits and b) we could take advantage of modern Go module tooling that essentially obviates the need for vendoring entirely.

In the topologyawarewg and networkplumbingwg I've already merged PRs that remove vendoring from a bunch of their repos and that's helped tremendously in simplifying life for those of us who have to build components using internal build tooling. Would it be possible to remove vendoring from the scheduler-plugins repo?

What did you expect to happen?

n/a

How can we reproduce it (as minimally and precisely as possible)?

No response

Anything else we need to know?

No response

Kubernetes version

all

Scheduler Plugins version

all

[jdtuhui]

/assign

[zwpaper]

we may need some input from @Huang-Wei before we work on this,

WDYT? @Huang-Wei

[Huang-Wei]

Let's use next release's branch (v1.30) to exercise this.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[binacs]

/remove-lifecycle stale

/assign

Considering this issue has not been updated for a long time, I opened another pull request to resolve it. Please refer to https://github.com/kubernetes-sigs/scheduler-plugins/pull/834