Add session notes - Leadership Summit
Add session notes - Leadership Summit
This commit is contained in:
nyener
parent
c63ad0ebc6
commit
6329c17d31
|
|
@ -0,0 +1,108 @@
|
|||
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
|
||||
|
||||
### Conclusions
|
||||
|
||||
#### Key Takeaways / Analysis of Situation
|
||||
|
||||
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||
|
||||
Specific Action Items (& Owners)
|
||||
|
||||
[Link to original
|
||||
doc](https://docs.google.com/document/d/1bWx40ASZ-6eKvCJO26l84qvYdNSAY-vHAKTMRWS7yyE/edit?usp=sharing)
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
Project Goals & Roadmap
|
||||
=======================
|
||||
|
||||
Identify the following before beginning your session. Do not move
|
||||
forward until these are decided / assigned:
|
||||
|
||||
- **Session Topic**: Project Goals and Roadmap
|
||||
- **Topic Facilitator(s)**: Apart Sinha, Google & Ihop Dvoretskyi,
|
||||
Mirantis
|
||||
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||
Nilay Yener
|
||||
- **Person responsible for converting to Markdown & uploading to
|
||||
Github:** nyener@
|
||||
|
||||
### Session Notes
|
||||
|
||||
(primarily discussion, for the presentation see:
|
||||
[Link](https://docs.google.com/presentation/d/1XXHk-oy-8eeqGMGRHQwOolOV4hFHlLu-KDpoXuU-C74/edit?usp=drivesdk)
|
||||
)
|
||||
|
||||
BGrant: Need help formalizing the proposal process, it’s not documented,
|
||||
need to automate assignment of the proposals, reach out to Brian Grant -
|
||||
|
||||
- Q: Don’t we want to stop taking features? A: We’ll take the idea,
|
||||
but not necessarily implement
|
||||
|
||||
Anecdote: IBM has struggled with how to contribute Lots of cross-SIG
|
||||
implementations, needs improvement Containerization growth 3% to 15% in
|
||||
a year Lower number than expected of companies doing orchestration ECS
|
||||
is at the top
|
||||
|
||||
- Q: Does Docker mean the docker runtime? A: Yes. Not swarm or orch
|
||||
tools, data is very consistent across surveys - means we need to be
|
||||
a strong community and understand the roadmap implications of the
|
||||
users. Last docker survey said people use Docker for development
|
||||
|
||||
Aparna: We’re aware of the developer experience, but it needs more
|
||||
attention
|
||||
|
||||
Node has a huge surface area, and we saw in Borg as well. Every feature
|
||||
touches node/API Machinery
|
||||
|
||||
M Rubin: Perception piece that it’s easy to tie something to node, so it’s an easy place to throw things
|
||||
|
||||
BGrant:Need to take that into account when triaging
|
||||
|
||||
BGrant: check out Istio
|
||||
|
||||
MRubin: Need to look at HPC more
|
||||
|
||||
Bburns: More conflict re: numa vs.
|
||||
stable kubernetes
|
||||
|
||||
Etune: The list was not authoritative
|
||||
|
||||
Bburns: Are we after people with “deep pockets” or are we after the community?
|
||||
|
||||
Jbeda:
|
||||
work on decoupling over prioritizing new features in the wrong direction
|
||||
|
||||
R Hirschfeld: the initial build experience is very important to overall
|
||||
community health
|
||||
|
||||
M Rubin: need to make deprio clear, and why Need to
|
||||
make it clear that we’re working on first getting things out of k/k SIGs
|
||||
have the ability to set the roadmap
|
||||
|
||||
BGrant: lots of critical features
|
||||
that big users need i.e. RBAC, in beta over introducing new APIs, some
|
||||
users will not use non-GA features
|
||||
|
||||
### Conclusions
|
||||
|
||||
#### Key Takeaways / Analysis of Situation
|
||||
|
||||
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||
|
||||
Specific Action Items (& Owners)
|
||||
|
||||
[Link to original
|
||||
doc](https://docs.google.com/document/d/1tIGA2V04C7iAqvMvUa_udy2pPbbWEr6qqlC1piMazjg/edit?usp=sharing)
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
Updates : Governance & CNCF
|
||||
===========================
|
||||
|
||||
Identify the following before beginning your session. Do not move
|
||||
forward until these are decided / assigned:
|
||||
|
||||
- **Session Topic**: Updates : Governance & CNCF
|
||||
- **Topic Facilitator(s)**: Brian Grant, Google & Brandon Philips,
|
||||
CoreOS
|
||||
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||
Nilay Yener
|
||||
- **Person responsible for converting to Markdown & uploading to
|
||||
Github:** nyener@
|
||||
|
||||
### Session Notes
|
||||
|
||||
[Link](https://docs.google.com/presentation/d/1pc-nayPpUZQlS10VPKqc-fb0Y3FXeSLeGAJ81g8NsCg/edit#slide=id.p)
|
||||
|
||||
BGrant: Please do not rathole on minutiae, but please comment on the
|
||||
governance documents, we need to understand that this formalizes the
|
||||
escalation path B Philips: Steering committee is focused on watching the
|
||||
details
|
||||
|
||||
Q: Vertical is vertical in the diagram? A: Bgrant: we need to understand
|
||||
how cross-cutting decisions are made and organized
|
||||
|
||||
Q: Aaron C: Escalation should be clearly defined A: BGrant: We want each
|
||||
SIG to have a formal charter for responsibility and authority + scope
|
||||
|
||||
Q: Aparna: Definition of what a SIG is? A: Def of what a SIG can cover
|
||||
and what it is, steering committee oversees new SIGs, need to resolve
|
||||
overlap BGrant: Every identifiable part of the project needs a SIG owner
|
||||
|
||||
Q: Criteria for level of activity? A: Yes
|
||||
|
||||
Q: ETune: is the steering committee deciding what a Kubernetes component
|
||||
is A: yes, but not the bootstrap
|
||||
|
||||
Q: What is the responsibilities of SIG to communicate with other SIGs?
|
||||
A: This is a very large item of discussion and out of scope
|
||||
|
||||
Q: R Hirschfeld: How do we handle cross-cutting concerns? i.e.
|
||||
Operations / tie-breaking authority in the steering committee? A:
|
||||
Working groups, SIGs etc can do it, but we need to figure that out /
|
||||
yes, e.g. the supreme court Please read the docs Q: Examples of working
|
||||
groups? Would snapshots be one? A: jobs, internationalization ETune:
|
||||
it’s a mailing list + sharing the activities
|
||||
|
||||
Bgrant: the eligibility for voting is wrong, we know it, and part of
|
||||
this is increasing inclusivity Comments until 6/15, in place by 8/1 \~
|
||||
need to build tools and mechanisms for voting, need help with this
|
||||
|
||||
Need help with this process, this is a big hurdle for CNCF graduation
|
||||
BGrant is on the CNCF technical oversight committee, meetings Tuesdays
|
||||
8am PST
|
||||
|
||||
Steering Committee Nominations - get notified : https://goo.gl/bQBQMu
|
||||
|
||||
Q: Aparna: CNCF has been offering training, governing board meeting
|
||||
wanted to mention “CNCF has no ambition to interfere with the community,
|
||||
CNCF is willing to devote as much as possible” A:
|
||||
|
||||
Q: Same guidelines as the Linux foundation? A: 2 Kubernetes seats, one
|
||||
the first year
|
||||
|
||||
Q: Aaron C: CNCF doesn’t define the how but what? A: There are some
|
||||
bars, but not that many requirements. Can be discovered on the site and
|
||||
in the charter. V 1.0 of the graduation criteria is out. CoC needs to be
|
||||
re-written.
|
||||
|
||||
Election by 8/13
|
||||
|
||||
Q: Aaron C: How do we formalize for 1.8? A: Bootstrap committee and SIGs
|
||||
until the full committee is formed, Not a clear definition of feature
|
||||
size, and that needs to evolve, need people to chip in Lazy consensus
|
||||
worked for 1.6 decision making, so we should continue that for now
|
||||
Decide here that 1.8 is stabilization, finishing things, need to get
|
||||
everything GA this year
|
||||
|
||||
Q: Do we skip features lined up for 1.8 and move to 1.9? A: The
|
||||
stabilization work will help this
|
||||
|
||||
Q: Where do we handle this today? Steering committee needs to intervene
|
||||
when necessary Resource gaps need to be addressed Aaron C: First thing a
|
||||
SIG needs to do is formalize what a SIG owns Need to create a charter
|
||||
template ASAP then give SIGs time to come up with charter All project
|
||||
pieces need to be categorized as owned by some SIG
|
||||
|
||||
### Conclusions
|
||||
|
||||
#### Key Takeaways / Analysis of Situation
|
||||
|
||||
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||
|
||||
Specific Action Items (& Owners)
|
||||
|
||||
[Link to original
|
||||
doc](https://docs.google.com/document/d/1Ch-aH_dyuL7pXv5ic-2Rb1j5w4us2FCj3U0cgpQTnOw/edit)
|
||||
|
|
@ -0,0 +1,193 @@
|
|||
Architectural Roadmap
|
||||
=====================
|
||||
|
||||
Identify the following before beginning your session. Do not move
|
||||
forward until these are decided / assigned:
|
||||
|
||||
- **Session Topic**: Architectural Roadmap
|
||||
- **Topic Facilitator(s)**: Brian Grant
|
||||
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||
Nilay Yener
|
||||
- **Person responsible for converting to Markdown & uploading to
|
||||
Github:** nyener@
|
||||
|
||||
### Session Notes
|
||||
|
||||
[Link](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit)
|
||||
|
||||
Not using “core” because it is overloaded - substituting “nucleus”
|
||||
instead \~ absolute necessities for Kubernetes to function
|
||||
|
||||
Q: Aaron C: What is an add-on? A: Concept is any Kubernetes resource
|
||||
managed by the cluster for its own internal consistency/function - e.g.
|
||||
extensible cluster functionality / pulling context
|
||||
|
||||
Q: Are CNI also add-ons? A: Yes.
|
||||
|
||||
Q: How do we differentiate between addons and required addons? A: Part
|
||||
of conformance, if they are managed as part of the cluster, by the
|
||||
cluster manager, they are an addon \~ like a driver in the kernel
|
||||
|
||||
Q: Helm Charts tied to lifecycle of the cluster? A: There’s an issue for
|
||||
addons v2 via Justin Santa Barbara, but the lifecycle is different than
|
||||
for Helm - it’s possible to use charts, but would prefer sources
|
||||
accessed directly for bootstrapping
|
||||
|
||||
Q: How do addons get scheduled? Daemon sets only? A: bash script,
|
||||
one-shot scheduler, in Google it’s called “babysitter” and predates
|
||||
Borg, inspired kubelet “run once” mode, addon manager manages the
|
||||
replicaset object
|
||||
|
||||
Q: Are these strict layers? The concept of layers introduces hierarchy
|
||||
and precedence (governance does not have an implicit reliance on
|
||||
application layer) A: Trying to avoid 9 layers, so we need flexibility
|
||||
in the release process, more modular the better
|
||||
|
||||
Q: Eric Tune: Nucleus : abstract my cloud, Application: Run my workload,
|
||||
Governance: Enterprise I need to do stuff A: Yes
|
||||
|
||||
Comment: Let’s make sure we keep this as simple as possible. BG: We want
|
||||
to ensure that the user community is not significantly impacted, nor
|
||||
cluster operators, one change needed will be breaking up the monolithic
|
||||
V1 API group, pods in V1 group, pods in other API group, want to evolve
|
||||
them more easily.
|
||||
|
||||
Q: Addons are at the lowest level, but we might want higher level addons
|
||||
A: Bootstrapping needs attention, similar to other self-hosting issues,
|
||||
some people may not run the aggregated API server
|
||||
|
||||
Q: Three implications: code organization / nucleus and others would be
|
||||
in one repo versus another. Where is the line? 2. SIG alignment 3.
|
||||
roadmap / where do we invest more? A: 1. Code org is another discussion,
|
||||
but there’s a desire for more modularity. SIGs with their own codebases.
|
||||
2. 3. e.g. Priority for admission controller was increased for 1.7, want
|
||||
to make API aggregation important
|
||||
|
||||
Q: What are the lifecycles around each layer? Would they release
|
||||
separately? A: There’s the release cadence, introduction of new
|
||||
features, and the evolution of the APIs -- may adopt git flow processes
|
||||
|
||||
Q: Adding extension points is the only thing that should permit more
|
||||
technical debt A: Agreed, but may also apply to cloud providers
|
||||
|
||||
C: Need to be able to say no to things that are obsoleted by the list
|
||||
|
||||
C: Cloud provider extension work is being done by one person - this is
|
||||
not a good thing
|
||||
|
||||
### Conclusions
|
||||
|
||||
#### Key Takeaways / Analysis of Situation
|
||||
|
||||
Are there questions/concerns?
|
||||
|
||||
We need to get feedback on the docs and diagrams.
|
||||
|
||||
When these are happening, we expect support from all the SIGs, and how
|
||||
to work this into backlogs.
|
||||
|
||||
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||
|
||||
Specific Action Items (& Owners)
|
||||
|
||||
Architectural Roadmap
|
||||
=====================
|
||||
|
||||
Identify the following before beginning your session. Do not move
|
||||
forward until these are decided / assigned:
|
||||
|
||||
- **Session Topic**: Architectural Roadmap
|
||||
- **Topic Facilitator(s)**: Brian Grant
|
||||
- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars,
|
||||
Nilay Yener
|
||||
- **Person responsible for converting to Markdown & uploading to
|
||||
Github:** nyener@
|
||||
|
||||
### Session Notes
|
||||
|
||||
[Link](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit)
|
||||
|
||||
Not using “core” because it is overloaded - substituting “nucleus”
|
||||
instead \~ absolute necessities for Kubernetes to function
|
||||
|
||||
Q: Aaron C: What is an add-on? A: Concept is any Kubernetes resource
|
||||
managed by the cluster for its own internal consistency/function - e.g.
|
||||
extensible cluster functionality / pulling context
|
||||
|
||||
Q: Are CNI also add-ons? A: Yes.
|
||||
|
||||
Q: How do we differentiate between addons and required addons? A: Part
|
||||
of conformance, if they are managed as part of the cluster, by the
|
||||
cluster manager, they are an addon \~ like a driver in the kernel
|
||||
|
||||
Q: Helm Charts tied to lifecycle of the cluster? A: There’s an issue for
|
||||
addons v2 via Justin Santa Barbara, but the lifecycle is different than
|
||||
for Helm - it’s possible to use charts, but would prefer sources
|
||||
accessed directly for bootstrapping
|
||||
|
||||
Q: How do addons get scheduled? Daemon sets only? A: bash script,
|
||||
one-shot scheduler, in Google it’s called “babysitter” and predates
|
||||
Borg, inspired kubelet “run once” mode, addon manager manages the
|
||||
replicaset object
|
||||
|
||||
Q: Are these strict layers? The concept of layers introduces hierarchy
|
||||
and precedence (governance does not have an implicit reliance on
|
||||
application layer) A: Trying to avoid 9 layers, so we need flexibility
|
||||
in the release process, more modular the better
|
||||
|
||||
Q: Eric Tune: Nucleus : abstract my cloud, Application: Run my workload,
|
||||
Governance: Enterprise I need to do stuff A: Yes
|
||||
|
||||
Comment: Let’s make sure we keep this as simple as possible. BG: We want
|
||||
to ensure that the user community is not significantly impacted, nor
|
||||
cluster operators, one change needed will be breaking up the monolithic
|
||||
V1 API group, pods in V1 group, pods in other API group, want to evolve
|
||||
them more easily.
|
||||
|
||||
Q: Addons are at the lowest level, but we might want higher level addons
|
||||
A: Bootstrapping needs attention, similar to other self-hosting issues,
|
||||
some people may not run the aggregated API server
|
||||
|
||||
Q: Three implications: code organization / nucleus and others would be
|
||||
in one repo versus another. Where is the line? 2. SIG alignment 3.
|
||||
roadmap / where do we invest more? A: 1. Code org is another discussion,
|
||||
but there’s a desire for more modularity. SIGs with their own codebases.
|
||||
2. 3. e.g. Priority for admission controller was increased for 1.7, want
|
||||
to make API aggregation important
|
||||
|
||||
Q: What are the lifecycles around each layer? Would they release
|
||||
separately? A: There’s the release cadence, introduction of new
|
||||
features, and the evolution of the APIs -- may adopt git flow processes
|
||||
|
||||
Q: Adding extension points is the only thing that should permit more
|
||||
technical debt A: Agreed, but may also apply to cloud providers
|
||||
|
||||
C: Need to be able to say no to things that are obsoleted by the list
|
||||
|
||||
C: Cloud provider extension work is being done by one person - this is
|
||||
not a good thing
|
||||
|
||||
### Conclusions
|
||||
|
||||
#### Key Takeaways / Analysis of Situation
|
||||
|
||||
Are there questions/concerns?
|
||||
|
||||
We need to get feedback on the docs and diagrams.
|
||||
|
||||
When these are happening, we expect support from all the SIGs, and how
|
||||
to work this into backlogs.
|
||||
|
||||
#### Recommendations & Decisions Moving Forward (High-Level)
|
||||
|
||||
Specific Action Items (& Owners)
|
||||
|
||||
Action Item |Owner(s)
|
||||
------------|------------
|
||||
SIG Architecture Creation (ratified per unanimous vote, 6/3/2017) | Jaice Singer DuMars, Brian Grant Lead
|
||||
Refine and approve Brian’s architecture | SIG Architecture
|
||||
|
||||
[Link to original
|
||||
doc](https://docs.google.com/document/d/1nD3Y1-Tbb-hhSNg6TGPRLxKSzIuRSnVfdHginl0brrc/edit#)
|
||||
[Link to original
|
||||
doc](https://docs.google.com/document/d/1nD3Y1-Tbb-hhSNg6TGPRLxKSzIuRSnVfdHginl0brrc/edit#)
|
||||
Loading…
Reference in New Issue