Add session notes - Leadership Summit

Add session notes - Leadership Summit

4 files changed, 480 insertions, 0 deletions

diff --git a/community/2017-events/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md b/community/2017-events/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md
new file mode 100644
index 00000000..05287aad
--- /dev/null
+++ b/community/2017-events/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md
@@ -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)
diff --git a/community/2017-events/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md b/community/2017-events/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md
new file mode 100644
index 00000000..453b3931
--- /dev/null
+++ b/community/2017-events/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md
@@ -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)
diff --git a/community/2017-events/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md b/community/2017-events/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md
new file mode 100644
index 00000000..7e49baa8
--- /dev/null
+++ b/community/2017-events/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md
@@ -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)
diff --git a/community/2017-events/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md b/community/2017-events/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md
new file mode 100644
index 00000000..8349c40d
--- /dev/null
+++ b/community/2017-events/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md
@@ -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#)