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 000000000..05287aad3 --- /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 000000000..453b39318 --- /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 000000000..7e49baa84 --- /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 000000000..8349c40d1 --- /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#)