From d9d90fb97c60f492ad82a3ed2607b7ceb24ea0fb Mon Sep 17 00:00:00 2001 From: nyener Date: Tue, 20 Jun 2017 21:51:38 -0700 Subject: [PATCH 1/3] Session Notes 2017 Leadership Summit session notes --- ...IONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md | 139 ++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md diff --git a/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md b/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md new file mode 100644 index 000000000..024f0ed21 --- /dev/null +++ b/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md @@ -0,0 +1,139 @@ +Presentations From Breakouts with Call to Actions +================================================= + +Identify the following before beginning your session. Do not move +forward until these are decided / assigned: + +- **Session Topic**: Presentations From Breakouts with Call to Actions +- **Topic Facilitator(s)**: snovotny@ +- **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars, + Nilay Yener +- **Person responsible for converting to Markdown & uploading to + Github:** nyener@ + +### Session Notes + +#### SIG GOVERNANCE AND SIG CHECK IN + +- Discussed cross cutting SIG concerns and how to accomplish +- Create certificate for SIGs +- SIG Leads office hours +- SIG Leads mailing list \~ open vs. closed -- read-only +- Private comms will happen in committees + +#### IDENTIFYING AREAS THAT ARE FALLING THROUGH THE CRACKS + +Focused a lot on other contributions that are getting lost: + +- want to help other people and companies take part in non-coding + activities +- How do we call out other contributions +- Incentives for other contributions +- SIGs need to harness the value in Kubernetes +- SIGs might have different roles, i.e. docs, etc. +- Identify and fill roles +- No unfunded mandates, calling out companies that contribute +- Recognize companies that contribute maintenance +- Credits for the release +- Incentivise individuals as well +- Need to be cognizant of company marketing around Kubernetes +- By recognizing roles, you can provide continuity and pride, e.g. + k8sbot +- Conformance working group +- We need to defend the trademark or lose it +- We need to identify repositories that use the kubernetes- taxonomy +- Develop a better way to assess contributions, leaderboard issue (see + action item) + +#### CODE ORGANIZATION + IMPROVING THE RELEASE PROCESS + +- Brian's presentation on why we wanted to break out the repos +- Accepting limitations in GitHub +- Service catalog is already doing this +- Near term direction untangling dependencies +- How are we executing with kubectl +- Integration and testing across different repos is hard +- SIGs involved are API Machinery, CLI and Cluster Lifecycle +- Need a working group to sort out the approach + +#### BUILDING COMMUNITY EFFECTIVENESS + +- Talked about how to get more engagement in meetings +- introductions +- pair mentors +- find out what people want to do +- don't put mission critical work on new contribs +- watch time zones +- keep SIG meeting as status, focus on 1:1 for work +- off-weeks for office hours +- User on-boarding SIG +- education +- 1:1s +- welcome wagon +- Cluster Ops working on this for operators + +#### What went well? + +- Breakouts +- Networking time +- Face to face talking +- More content - more breaks +- Continued note taking and making things available. Templates are + really helpful +- 3 SIGs had a cross SIG collaboration +- Morning single track + +#### What would you do differently? + +- bad timing with code freeze +- Record sessions so there's a better record +- Red Hat was under-represented, so we should consider East +- Not a lot of decisions were made, how do we do things instead of + just talking about it? +- "Stability is important" but there's not an action item +- Lack of specific focus +- More engagement with the agenda ahead of time + +#### Risks + +- Too little governance +- Conformance from the CNCF +- Stability is not getting worked on +- How do you balance convergence vs. divergence +- We are not getting true customer voice - what user experience is - + get feedback from product. +- We need to make it easier for people who wants to find out what + Kubernetes is about + +### Conclusions + +#### Key Takeaways / Analysis of Situation + +#### Recommendations & Decisions Moving Forward (High-Level) + +Specific Action Items (& Owners) + + Action Item Owner(s) + --------------------------------------------------------------------------------------------------- --------------------------------- + Read-only on SIG-Leads list instead of closed SIG Cloud SIG Leads mailing list + Proposal for how we recognize contributions Quinton Hoole + Need a SIG owner on utilities Tim Hockin + Ladders Kris N + Regular community check-ins Brian Grant + Describe the end state and then assign breakout work to SIGs. Working group needs to be organized Brian Grant + Working group organization or a SIG that oversees this Machinery CLI Cluster Lifecycle + +SIG Meetings\ +\* Intro \* Pair mentors \* Find out what people want to do \* Off weeks +for office hours \* find out what people want to do \* don't put mission +critical work on new contribs \* watch time zones \* keep SIG meeting as +status, focus on 1:1 for works + +SIG User Onboarding \* education \* 1:1s \* welcome wagon \* Cluster Ops +working on this for operators + +Communicate stability decision User support rotation as a way of getting +real-world feedback + +[Link to original +doc](https://docs.google.com/document/d/1I4abWaWP9qa2XV8Q8b7ENxIby-EvsyXRrt90SS19Ldc/edit?usp=sharing) From c63ad0ebc6ca3210927c512a2412adef5d069ad7 Mon Sep 17 00:00:00 2001 From: nyener Date: Tue, 20 Jun 2017 22:02:18 -0700 Subject: [PATCH 2/3] session notes - update action items update action items --- ...IONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md | 41 +++++++++++-------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md b/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md index 024f0ed21..fa52f1dcc 100644 --- a/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md +++ b/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md @@ -5,7 +5,7 @@ Identify the following before beginning your session. Do not move forward until these are decided / assigned: - **Session Topic**: Presentations From Breakouts with Call to Actions -- **Topic Facilitator(s)**: snovotny@ +- **Topic Facilitator(s)**: sarahnovotny@ - **Note-taker(s) (Collaborating on this doc)**: Jason Singer DuMars, Nilay Yener - **Person responsible for converting to Markdown & uploading to @@ -113,24 +113,31 @@ Focused a lot on other contributions that are getting lost: Specific Action Items (& Owners) - Action Item Owner(s) - --------------------------------------------------------------------------------------------------- --------------------------------- - Read-only on SIG-Leads list instead of closed SIG Cloud SIG Leads mailing list - Proposal for how we recognize contributions Quinton Hoole - Need a SIG owner on utilities Tim Hockin - Ladders Kris N - Regular community check-ins Brian Grant - Describe the end state and then assign breakout work to SIGs. Working group needs to be organized Brian Grant - Working group organization or a SIG that oversees this Machinery CLI Cluster Lifecycle +Action Item |Owner(s) +------------|------------ +Read-only on SIG-Leads list instead of closed SIG Cloud | SIG Leads mailing list +Proposal for how we recognize contributions | Quinton Hoole +Need a SIG owner on utilities | Tim Hockin +Ladders | Kris N +Regular community check-ins | Brian Grant +Describe the end state and then assign breakout work to SIGs. Working group needs to be organized | Brian Grant +Working group organization or a SIG that oversees this | Machinery CLI Cluster Lifecycle -SIG Meetings\ -\* Intro \* Pair mentors \* Find out what people want to do \* Off weeks -for office hours \* find out what people want to do \* don't put mission -critical work on new contribs \* watch time zones \* keep SIG meeting as -status, focus on 1:1 for works +SIG Meetings +* Intro +* Pair mentors +* Find out what people want to do +* Off weeks for office hours +* find out what people want to do +* don't put mission critical work on new contribs +* watch time zones +* keep SIG meeting as status, focus on 1:1 for works -SIG User Onboarding \* education \* 1:1s \* welcome wagon \* Cluster Ops -working on this for operators +SIG User Onboarding +* education +* 1:1s +* welcome wagon +* Cluster Ops working on this for operators Communicate stability decision User support rotation as a way of getting real-world feedback From 6329c17d316099ded44ada068617f3607dba2907 Mon Sep 17 00:00:00 2001 From: nyener Date: Tue, 20 Jun 2017 23:46:40 -0700 Subject: [PATCH 3/3] Add session notes - Leadership Summit Add session notes - Leadership Summit --- .../0905-0930_STATE_OF_THE_KUBE.md | 108 ++++++++++ .../0940-1000_PROJECT_GOALS_ROADMAP.md | 81 ++++++++ .../1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md | 98 +++++++++ .../1145_1245_ARCHITECTURAL_ROADMAP.md | 193 ++++++++++++++++++ 4 files changed, 480 insertions(+) create mode 100644 community/2017-events/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md create mode 100644 community/2017-events/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md create mode 100644 community/2017-events/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md create mode 100644 community/2017-events/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md 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#)