Tools for evaluating dependency updates to Kubernetes

[dims]

NOTE: This is part of the LFX mentorship program

Implement command line utilities that can help Kubernetes developers evaluate new dependencies by capturing statistics/metrics and estimating cost of adding something new. This will involve diving deep into golang dependency chains (transitive/shared dependencies) and coming up with new metrics to estimate how burdensome something new can be or how much we will save by getting rid of something so we can prioritize work and get more efficient from a developer workflow perspective.

For more context see these code-organization meeting notes and this one

[neolit123]

/sig architecture
/area code-organization

[neolit123]

/triage accepted

[alenkacz]

OMG this is amazing, I want this. I've spent last couple of weeks upgrading bunch of kubernetes related deps in several projects and I was thinking about something like this a lot. 🙏

I wish I could work on this :)

[dims]

Prior art / background research:

• Dependency Graph For Analysis #76395
• https://golang.org/ref/mod (search for "go list")
• https://seankhliao.com/blog/12020-10-03-go-list-patterns/
• https://www.alexedwards.net/blog/an-overview-of-go-tooling
• https://github.com/loov/goda
• https://github.com/KyleBanks/depth
• https://github.com/google/godepq

[navidshaikh]

I've some experience in writing command line utilities and I'd like to collaborate on this. Going to parse the references linked above.

[alenkacz]

@navidshaikh feel free to sign up to this project via https://www.cncf.io/blog/2021/02/03/cncf-lfx-projects-are-open-for-spring-term-2021-apply-now-for-a-mentorship-opportunity/ if you're interested in this

[abhaykatheria]

I think if we can get the metadata of all the dependencies (existing and the new one) using goda, and then classify them as incoming or shared.
After getting the metadata we can create a report with some investigatory features like :

• sort by LoC.
• sort by no. of deps (new incoming deps)
• and maybe some other metric.

Then to make it less sore to the eyes, create an HTML report for the same with a dependency graph and features listed above, it can also have links to the respected module repositories where developers can go check out how active the module development is.
After proper investigation developer can decide whether or not to bring in the new dep.
Please point out if I am missing something.
P.S: I am writing this under the assumption that we are currently only concerned with adding new modules not deleting them.

[dims]

@abhaykatheria good find, yes we want to highlight cost of adding things, but also celebrate the wins when we drop something.

[fejta-bot]

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-contributor-experience at kubernetes/community.
/lifecycle stale

[RinkiyaKeDad]

/remove-lifecycle stale

[RinkiyaKeDad]

@dims can we close this now? 🙂

[dims]

yes! thanks a ton @RinkiyaKeDad

/close

[k8s-ci-robot]

@dims: Closing this issue.

In response to this:

yes! thanks a ton @RinkiyaKeDad

/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.