State of the Kube

Identify the following before beginning your session. Do not move forward until these are decided / assigned:

  • Session Topic: STATE OF THE KUBE
  • Topic Facilitator(s): Tim Hockin
  • Note-taker(s) (Collaborating on this doc): Jason Singer DuMars, Nilay Yener
  • Person responsible for converting to Markdown & uploading to Github: nyener@

Session Notes

  • 789 companies
  • 15 timezones
  • 41.3 commits daily
  • 2505 devs
  • 100 days between releases
  • 3549 commits since v1.6.0
  • 200+ meetups
  • 8365 Github forks
  • 4793 open issues on k/k
  • 26.6% commits from top 10 devs
  • 23642 stars
  • 658 open PRs

Needs SIG label is good on stale issues If it’s old and not relevant, close it Open PRs are a problem - should the be closed and reopened when they are ready to work

Companies are not necessarily easy to identify by contribution

Growth : Change of the number of commits release by release

Do we want more contributors? Brendan Burns: Maybe not

E Tune: We can’t continue having more and more content

B Burns: We need to make it easier to contribute code

Lots of hard problems remain. This place is even beyond what has been done at Google

Generated code is a huge problem as well

DOCS API reference is a problem

People and companies want to contribute/consume but it’s not easy to do, e.g. namespace best practices

B Burns: there’s not one best practice

Stability first and features second - needs to be front of mind, SIG silos cannot exist

etune: Aren’t update scripts to help keep organized part of the contribx problem?

bburns: there can be organic parts of sub-projects, there’s no reason to html docs in there for example

jbeda: we over-focus on kubernetes/kubernetes

thockin: we can break it up, but k/k is still the gravity well

Getting time and leeway to execute on these things is hard/impossible

We have to assign responsibility and divvy up the work. No one owns it so nothing gets done

SIGs have some part but not all of it, no unified view, and do SIGs know what they own

Conformance is going to be a big thing, especially as more integration happens

Q&A :

  • Q: Are we pivoting from accepting technical debt? Yes. But not a hard pivot. Instability will cause us to fail A: BBurns: We’ve gone past the edge of what is necessary, and now we’re in the area of value add via stability

  • Q: Are we going to decide to pay down our debt? A: Given a choice between feature/fix, we should err on the side of fix , core should be stable, and the bar has gone up fr

  • Q: Are we missing that message? A: We’re talking about it, but not doing it - more on this later

  • Q: Did 1.6 accomplish stability? Do we need to re-brand these? A: Some SIGs did, yes

  • Q: Do we need to formalize tech debt burn down? Show of hands… A: Deferred, but everyone seems interested in stabilizing k/k


Key Takeaways / Analysis of Situation

Recommendations & Decisions Moving Forward (High-Level)

Specific Action Items (& Owners)

Link to original doc