From ff5c9a0e87dd61ce94eeb1b3a91fd0a017adabd6 Mon Sep 17 00:00:00 2001 From: parispittman Date: Wed, 27 Dec 2017 14:48:20 -0800 Subject: reorganizing to make sense, creating communications folder, adding slack guide, etc. --- communication.md | 21 +- communication/K8sYoutubeCollaboration.md | 39 +++ communication/README.md | 1 + communication/slack-guidelines.md | 84 ++++++ community/2016-events/Kubernetes_1st_Bday.md | 23 -- .../developer-summit-2016/KubDevSummitVoting.md | 33 -- .../developer-summit-2016/Kubernetes_Dev_Summit.md | 96 ------ .../application_service_definition_notes.md | 48 --- .../cluster_federation_notes.md | 21 -- .../cluster_lifecycle_notes.md | 132 -------- .../developer-summit-2016/k8sDevSummitSchedule.pdf | Bin 54169 -> 0 bytes .../developer-summit-2016/statefulset_notes.md | 38 --- community/2016-events/fixit201606.md | 61 ---- .../05-leadership-summit/announcement.md | 26 -- .../session-notes/0300-0345_CODEORGANIZATION.md | 198 ------------ .../session-notes/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 ------------ .../session-notes/1345-1430_SIGGOVERNANCE.md | 107 ------- .../session-notes/1500-1545_COMMUNITY_LADDER.md | 75 ----- ...ENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md | 146 --------- .../05-leadership-summit/session-notes/readme.md | 6 - .../ContribSummitInformation.md | 70 ----- .../Meeting Room 4ABC - 1st set, Tues fishbowl.PNG | Bin 92389 -> 0 bytes ...ing Room 6A and 6B - 1st Set, Tues fishbowl.PNG | Bin 136041 -> 0 bytes .../breaking-up-the-monolith.md | 76 ----- .../cloud-native-design-refactoring-across-k8s.md | 60 ---- .../12-contributor-summit/cloud-provider.md | 86 ------ .../12-contributor-summit/container-identity.md | 168 ----------- .../current-state-of-client-libraries.md | 38 --- .../12-contributor-summit/dashboard-ux-breakout.md | 94 ------ .../enabling-kubernetes-ecosystem.md | 134 -------- .../12-contributor-summit/extending-kubernetes.md | 215 ------------- .../12-contributor-summit/feature-roadmap-2018.jpg | Bin 5468737 -> 0 bytes .../12-contributor-summit/feature-roadmap-2018.md | 336 --------------------- .../12-contributor-summit/feature-workflow.md | 85 ------ .../kubernetes-client-libraries-open-space.md | 68 ----- ...nboarding-new-developers-through-better-docs.md | 232 -------------- .../12-contributor-summit/role-of-sig-lead.md | 110 ------- .../scaling-new-contributors.md | 61 ---- ...ing-up-and-scaling-down-and-addon-management.md | 104 ------- .../2017-events/12-contributor-summit/schedule.png | Bin 155235 -> 0 bytes .../should-k8s-use-feature-branches.md | 113 ------- .../steering-committee-update.md | 47 --- .../whats-up-with-sig-cluster-lifecycle.md | 62 ---- community/K8sYoutubeCollaboration.md | 39 --- community/elections/2017/BALLOTS.csv | 310 ------------------- community/elections/2017/README.md | 77 ----- community/elections/2017/RESULTS.md | 53 ---- community/elections/2017/aaroncrickenberger_bio.md | 23 -- community/elections/2017/aaronschlesinger_bio.md | 53 ---- community/elections/2017/adnanabdulhussein_bio.md | 46 --- community/elections/2017/alexpollitt_bio.md | 27 -- community/elections/2017/calebamiles_bio.md | 52 ---- community/elections/2017/derekcarr_bio.md | 43 --- community/elections/2017/dougdavis_bio.md | 40 --- community/elections/2017/errordeveloper_bio.md | 33 -- community/elections/2017/idvoretskyi_bio.md | 24 -- community/elections/2017/jaicesingerdumars_bio.md | 20 -- community/elections/2017/kris-nova_bio.md | 36 --- community/elections/2017/mattfarina_bio.md | 23 -- community/elections/2017/michaelrubin_bio.md | 36 --- community/elections/2017/michellenoorali_bio.md | 35 --- community/elections/2017/pwittrock_bio.md | 55 ---- community/elections/2017/quintonhoole_bio.md | 66 ---- community/elections/2017/rhirschfeld_bio.md | 27 -- community/elections/2017/sebastiengoasguen_bio.md | 30 -- community/elections/2017/timothysc_bio.md | 26 -- community/elections/2017/vote_for_justinsb.md | 43 --- community/elections/README.md | 96 ------ community/office-hours.md | 76 ----- events/2016/Kubernetes_1st_Bday.md | 23 ++ .../developer-summit-2016/KubDevSummitVoting.md | 33 ++ .../developer-summit-2016/Kubernetes_Dev_Summit.md | 96 ++++++ .../application_service_definition_notes.md | 48 +++ .../cluster_federation_notes.md | 21 ++ .../cluster_lifecycle_notes.md | 132 ++++++++ .../developer-summit-2016/k8sDevSummitSchedule.pdf | Bin 0 -> 54169 bytes .../developer-summit-2016/statefulset_notes.md | 38 +++ events/2016/fixit201606.md | 61 ++++ events/2017/05-leadership-summit/announcement.md | 26 ++ .../session-notes/0300-0345_CODEORGANIZATION.md | 198 ++++++++++++ .../session-notes/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 ++++++++++++ .../session-notes/1345-1430_SIGGOVERNANCE.md | 107 +++++++ .../session-notes/1500-1545_COMMUNITY_LADDER.md | 75 +++++ ...ENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md | 146 +++++++++ .../05-leadership-summit/session-notes/readme.md | 6 + .../ContribSummitInformation.md | 70 +++++ .../Meeting Room 4ABC - 1st set, Tues fishbowl.PNG | Bin 0 -> 92389 bytes ...ing Room 6A and 6B - 1st Set, Tues fishbowl.PNG | Bin 0 -> 136041 bytes .../breaking-up-the-monolith.md | 76 +++++ .../cloud-native-design-refactoring-across-k8s.md | 60 ++++ .../2017/12-contributor-summit/cloud-provider.md | 86 ++++++ .../12-contributor-summit/container-identity.md | 168 +++++++++++ .../current-state-of-client-libraries.md | 38 +++ .../12-contributor-summit/dashboard-ux-breakout.md | 94 ++++++ .../enabling-kubernetes-ecosystem.md | 134 ++++++++ .../12-contributor-summit/extending-kubernetes.md | 215 +++++++++++++ .../12-contributor-summit/feature-roadmap-2018.jpg | Bin 0 -> 5468737 bytes .../12-contributor-summit/feature-roadmap-2018.md | 336 +++++++++++++++++++++ .../2017/12-contributor-summit/feature-workflow.md | 85 ++++++ .../kubernetes-client-libraries-open-space.md | 68 +++++ ...nboarding-new-developers-through-better-docs.md | 232 ++++++++++++++ .../2017/12-contributor-summit/role-of-sig-lead.md | 110 +++++++ .../scaling-new-contributors.md | 61 ++++ ...ing-up-and-scaling-down-and-addon-management.md | 104 +++++++ events/2017/12-contributor-summit/schedule.png | Bin 0 -> 155235 bytes .../should-k8s-use-feature-branches.md | 113 +++++++ .../steering-committee-update.md | 47 +++ .../whats-up-with-sig-cluster-lifecycle.md | 62 ++++ events/elections/2017/BALLOTS.csv | 310 +++++++++++++++++++ events/elections/2017/README.md | 77 +++++ events/elections/2017/RESULTS.md | 53 ++++ events/elections/2017/aaroncrickenberger_bio.md | 23 ++ events/elections/2017/aaronschlesinger_bio.md | 53 ++++ events/elections/2017/adnanabdulhussein_bio.md | 46 +++ events/elections/2017/alexpollitt_bio.md | 27 ++ events/elections/2017/calebamiles_bio.md | 52 ++++ events/elections/2017/derekcarr_bio.md | 43 +++ events/elections/2017/dougdavis_bio.md | 40 +++ events/elections/2017/errordeveloper_bio.md | 33 ++ events/elections/2017/idvoretskyi_bio.md | 24 ++ events/elections/2017/jaicesingerdumars_bio.md | 20 ++ events/elections/2017/kris-nova_bio.md | 36 +++ events/elections/2017/mattfarina_bio.md | 23 ++ events/elections/2017/michaelrubin_bio.md | 36 +++ events/elections/2017/michellenoorali_bio.md | 35 +++ events/elections/2017/pwittrock_bio.md | 55 ++++ events/elections/2017/quintonhoole_bio.md | 66 ++++ events/elections/2017/rhirschfeld_bio.md | 27 ++ events/elections/2017/sebastiengoasguen_bio.md | 30 ++ events/elections/2017/timothysc_bio.md | 26 ++ events/elections/2017/vote_for_justinsb.md | 43 +++ events/elections/README.md | 96 ++++++ events/office-hours.md | 76 +++++ 139 files changed, 5132 insertions(+), 5050 deletions(-) create mode 100644 communication/K8sYoutubeCollaboration.md create mode 100644 communication/README.md create mode 100644 communication/slack-guidelines.md delete mode 100644 community/2016-events/Kubernetes_1st_Bday.md delete mode 100644 community/2016-events/developer-summit-2016/KubDevSummitVoting.md delete mode 100644 community/2016-events/developer-summit-2016/Kubernetes_Dev_Summit.md delete mode 100644 community/2016-events/developer-summit-2016/application_service_definition_notes.md delete mode 100644 community/2016-events/developer-summit-2016/cluster_federation_notes.md delete mode 100644 community/2016-events/developer-summit-2016/cluster_lifecycle_notes.md delete mode 100644 community/2016-events/developer-summit-2016/k8sDevSummitSchedule.pdf delete mode 100644 community/2016-events/developer-summit-2016/statefulset_notes.md delete mode 100644 community/2016-events/fixit201606.md delete mode 100644 community/2017-events/05-leadership-summit/announcement.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md delete mode 100755 community/2017-events/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md delete mode 100644 community/2017-events/05-leadership-summit/session-notes/readme.md delete mode 100644 community/2017-events/12-contributor-summit/ContribSummitInformation.md delete mode 100644 community/2017-events/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG delete mode 100644 community/2017-events/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG delete mode 100644 community/2017-events/12-contributor-summit/breaking-up-the-monolith.md delete mode 100644 community/2017-events/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md delete mode 100644 community/2017-events/12-contributor-summit/cloud-provider.md delete mode 100644 community/2017-events/12-contributor-summit/container-identity.md delete mode 100644 community/2017-events/12-contributor-summit/current-state-of-client-libraries.md delete mode 100644 community/2017-events/12-contributor-summit/dashboard-ux-breakout.md delete mode 100644 community/2017-events/12-contributor-summit/enabling-kubernetes-ecosystem.md delete mode 100644 community/2017-events/12-contributor-summit/extending-kubernetes.md delete mode 100644 community/2017-events/12-contributor-summit/feature-roadmap-2018.jpg delete mode 100644 community/2017-events/12-contributor-summit/feature-roadmap-2018.md delete mode 100644 community/2017-events/12-contributor-summit/feature-workflow.md delete mode 100644 community/2017-events/12-contributor-summit/kubernetes-client-libraries-open-space.md delete mode 100644 community/2017-events/12-contributor-summit/onboarding-new-developers-through-better-docs.md delete mode 100644 community/2017-events/12-contributor-summit/role-of-sig-lead.md delete mode 100644 community/2017-events/12-contributor-summit/scaling-new-contributors.md delete mode 100644 community/2017-events/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md delete mode 100644 community/2017-events/12-contributor-summit/schedule.png delete mode 100644 community/2017-events/12-contributor-summit/should-k8s-use-feature-branches.md delete mode 100644 community/2017-events/12-contributor-summit/steering-committee-update.md delete mode 100644 community/2017-events/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md delete mode 100644 community/K8sYoutubeCollaboration.md delete mode 100644 community/elections/2017/BALLOTS.csv delete mode 100644 community/elections/2017/README.md delete mode 100644 community/elections/2017/RESULTS.md delete mode 100644 community/elections/2017/aaroncrickenberger_bio.md delete mode 100644 community/elections/2017/aaronschlesinger_bio.md delete mode 100644 community/elections/2017/adnanabdulhussein_bio.md delete mode 100644 community/elections/2017/alexpollitt_bio.md delete mode 100644 community/elections/2017/calebamiles_bio.md delete mode 100644 community/elections/2017/derekcarr_bio.md delete mode 100644 community/elections/2017/dougdavis_bio.md delete mode 100644 community/elections/2017/errordeveloper_bio.md delete mode 100644 community/elections/2017/idvoretskyi_bio.md delete mode 100644 community/elections/2017/jaicesingerdumars_bio.md delete mode 100644 community/elections/2017/kris-nova_bio.md delete mode 100644 community/elections/2017/mattfarina_bio.md delete mode 100644 community/elections/2017/michaelrubin_bio.md delete mode 100644 community/elections/2017/michellenoorali_bio.md delete mode 100644 community/elections/2017/pwittrock_bio.md delete mode 100644 community/elections/2017/quintonhoole_bio.md delete mode 100644 community/elections/2017/rhirschfeld_bio.md delete mode 100644 community/elections/2017/sebastiengoasguen_bio.md delete mode 100644 community/elections/2017/timothysc_bio.md delete mode 100644 community/elections/2017/vote_for_justinsb.md delete mode 100644 community/elections/README.md delete mode 100644 community/office-hours.md create mode 100644 events/2016/Kubernetes_1st_Bday.md create mode 100644 events/2016/developer-summit-2016/KubDevSummitVoting.md create mode 100644 events/2016/developer-summit-2016/Kubernetes_Dev_Summit.md create mode 100644 events/2016/developer-summit-2016/application_service_definition_notes.md create mode 100644 events/2016/developer-summit-2016/cluster_federation_notes.md create mode 100644 events/2016/developer-summit-2016/cluster_lifecycle_notes.md create mode 100644 events/2016/developer-summit-2016/k8sDevSummitSchedule.pdf create mode 100644 events/2016/developer-summit-2016/statefulset_notes.md create mode 100644 events/2016/fixit201606.md create mode 100644 events/2017/05-leadership-summit/announcement.md create mode 100644 events/2017/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md create mode 100644 events/2017/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md create mode 100644 events/2017/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md create mode 100644 events/2017/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md create mode 100644 events/2017/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md create mode 100755 events/2017/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md create mode 100644 events/2017/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md create mode 100644 events/2017/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md create mode 100644 events/2017/05-leadership-summit/session-notes/readme.md create mode 100644 events/2017/12-contributor-summit/ContribSummitInformation.md create mode 100644 events/2017/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG create mode 100644 events/2017/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG create mode 100644 events/2017/12-contributor-summit/breaking-up-the-monolith.md create mode 100644 events/2017/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md create mode 100644 events/2017/12-contributor-summit/cloud-provider.md create mode 100644 events/2017/12-contributor-summit/container-identity.md create mode 100644 events/2017/12-contributor-summit/current-state-of-client-libraries.md create mode 100644 events/2017/12-contributor-summit/dashboard-ux-breakout.md create mode 100644 events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md create mode 100644 events/2017/12-contributor-summit/extending-kubernetes.md create mode 100644 events/2017/12-contributor-summit/feature-roadmap-2018.jpg create mode 100644 events/2017/12-contributor-summit/feature-roadmap-2018.md create mode 100644 events/2017/12-contributor-summit/feature-workflow.md create mode 100644 events/2017/12-contributor-summit/kubernetes-client-libraries-open-space.md create mode 100644 events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md create mode 100644 events/2017/12-contributor-summit/role-of-sig-lead.md create mode 100644 events/2017/12-contributor-summit/scaling-new-contributors.md create mode 100644 events/2017/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md create mode 100644 events/2017/12-contributor-summit/schedule.png create mode 100644 events/2017/12-contributor-summit/should-k8s-use-feature-branches.md create mode 100644 events/2017/12-contributor-summit/steering-committee-update.md create mode 100644 events/2017/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md create mode 100644 events/elections/2017/BALLOTS.csv create mode 100644 events/elections/2017/README.md create mode 100644 events/elections/2017/RESULTS.md create mode 100644 events/elections/2017/aaroncrickenberger_bio.md create mode 100644 events/elections/2017/aaronschlesinger_bio.md create mode 100644 events/elections/2017/adnanabdulhussein_bio.md create mode 100644 events/elections/2017/alexpollitt_bio.md create mode 100644 events/elections/2017/calebamiles_bio.md create mode 100644 events/elections/2017/derekcarr_bio.md create mode 100644 events/elections/2017/dougdavis_bio.md create mode 100644 events/elections/2017/errordeveloper_bio.md create mode 100644 events/elections/2017/idvoretskyi_bio.md create mode 100644 events/elections/2017/jaicesingerdumars_bio.md create mode 100644 events/elections/2017/kris-nova_bio.md create mode 100644 events/elections/2017/mattfarina_bio.md create mode 100644 events/elections/2017/michaelrubin_bio.md create mode 100644 events/elections/2017/michellenoorali_bio.md create mode 100644 events/elections/2017/pwittrock_bio.md create mode 100644 events/elections/2017/quintonhoole_bio.md create mode 100644 events/elections/2017/rhirschfeld_bio.md create mode 100644 events/elections/2017/sebastiengoasguen_bio.md create mode 100644 events/elections/2017/timothysc_bio.md create mode 100644 events/elections/2017/vote_for_justinsb.md create mode 100644 events/elections/README.md create mode 100644 events/office-hours.md diff --git a/communication.md b/communication.md index dc2e5e31..66c4beb3 100644 --- a/communication.md +++ b/communication.md @@ -19,19 +19,16 @@ and meetings devoted to Kubernetes. ## Social Media -* [Twitter] -* [Google+] -* [blog] -* Pose questions and help answer them on [Slack][slack.k8s.io] or [Stack Overflow]. - -Most real time discussion happens at [kubernetes.slack.com]; -you can sign up at [slack.k8s.io]. - +* [Twitter](https://twitter.com/kubernetesio) +* [Blog](http://blog.kubernetes.io/) +* Pose questions and help answer them on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes). +* [Slack](slack.k8s.io) - sign up + +Real time discussion at kubernetes.slack.io: Discussions on most channels are archived at [kubernetes.slackarchive.io]. Start archiving by inviting the _slackarchive_ bot to a channel via `/invite @slackarchive`. -To add new channels, contact one of the admins -(briangrant, goltermann, jbeda, sarahnovotny and thockin). +To add new channels, contact one of the [admins] in the #slack-admins channel. Our guidelines are [here](/communication/slack-guidelines.md). ## Issues @@ -52,11 +49,11 @@ Users trade notes on the Google group ## Office Hours -Office hours are held once a month. Please refer to [this document](community/office-hours.md) to learn more. +Office hours are held once a month. Please refer to [this document](community/office-hours.md) to learn more. ## Weekly Meeting -We have PUBLIC and RECORDED [weekly meeting] every Thursday at 10am US Pacific Time. +We have PUBLIC and RECORDED [weekly meeting] every Thursday at 10am US Pacific Time over Zoom. Map that to your local time with this [timezone table]. diff --git a/communication/K8sYoutubeCollaboration.md b/communication/K8sYoutubeCollaboration.md new file mode 100644 index 00000000..d46c21a2 --- /dev/null +++ b/communication/K8sYoutubeCollaboration.md @@ -0,0 +1,39 @@ + +### Kubernetes Youtube Channel Collaboration +### + +#### Meeting Playlists +#### +The [Kubernetes Youtube Channel](https://www.youtube.com/channel/UCZ2bu0qutTOM0tHYa_jkIwg) has separate playlists for each SIG’s meeting recordings, as well as recordings for other meetings (i.e. Cloud Native, Kubernetes Community meetings). + +To better serve the community, we have setup [collaboration](https://support.google.com/youtube/answer/6109639) on these playlists, so that anyone with the appropriate link to the particular playlist can upload videos *to that particular playlist* (links & playlists are 1:1). + +Each SIG playlist’s link will be shared with the SIG’s leadership, and other playlists' links (i.e. Cloud Native) will be shared with the appropriate point(s) of contact. The SIG playlist links will be sent to the official SIG lead Google Groups. + +#### Uploading Guidelines for Collaborators +#### +Collaboration should simplify things for everyone, but with privilege comes responsibility :). We assume all playlist collaborators in the community will use things fairly and appropriately, subject to the guidelines below: + +1. Once collaboration is setup for each meeting recording playlist, the upload responsibility will fall on the SIG leaders or other appropriate point(s) of contact. Community managers (Sarah and Cameron) *will only be escalation for issues with those playlists* + +2. Please post only related content (mostly meeting recordings) in the appropriate playlists + - Posting of any exceedingly inappropriate content (i.e. NSFW content) will result in ***immediate*** suspension of privileges + +3. Please ensure all videos have the same naming format, which is: + - Kubernetes [Name of Playlist’s Group] YYYYMMDD + - i.e. Kubernetes SIG Service Catalog 20161129 + +4. All playlists need to be organized chronologically for ease of use, which is most easily done by selected “date added, newest” as the “Ordering” option in the playlist settings + +5. Please do not remove any already-published content from the playlists without checking with the community managers + +6. For any small issues that arise (i.e. improper naming / ordering), you may be asked by the community managers to attempt to resolve the issue yourselves + +7. Any egregious or habitual violation* of the above rules will result in suspension of collaboration privileges for the particular individual, or for the entire playlist if the individual can’t be identified + - If an individual is suspended, the playlist link will be remade and the new link will be shared with the non-offending individuals + - If *playlist* collaboration is suspended, uploading by community managers to the playlist of interest will ***not*** be a priority, and will likely occur on a delayed basis + - *Note that "habitual violation" means "more than 3 issues per quarter" + +Your community managers are happy to help with any questions that you may have and will do their best to help if anything goes wrong. Please get in touch via sarahnovotny *at* google *dot* com and jorge *at* heptio *dot* com + + diff --git a/communication/README.md b/communication/README.md new file mode 100644 index 00000000..a577084c --- /dev/null +++ b/communication/README.md @@ -0,0 +1 @@ +[placeholder for the future home of communication.md] diff --git a/communication/slack-guidelines.md b/communication/slack-guidelines.md new file mode 100644 index 00000000..1982e3f7 --- /dev/null +++ b/communication/slack-guidelines.md @@ -0,0 +1,84 @@ +# SLACK GUIDELINES + +Slack is the main communication platform for Kubernetes outside of our mailing lists. It’s important that conversation stays on topic in each channel, and that everyone abides by the Code of Conduct. We have over 30,000 members who should all expect to have a positive experience. + +Chat is searchable and public. Do not make comments that you would not say on a video recording or in another public space. Please be courtesy to others. + +`@here` and `@channel` should be used rarely. Members will receive notifications from these commands and we are a global project - please be kind. Note: `@all` is only to be used by admins. + +## CODE OF CONDUCT +Kubernetes adheres to Cloud Native Compute Foundation's [Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) throughout the project including on all communication mediums. + +## ADMINS +(by Slack ID and timezone) +* caniszczyk - CT +* ihor - CET +* jdumars - ET +* jorge - CT +* paris - PT + +Slack Admins should make sure to mention this in the “What I do” section of their Slack profile, as well as for which time zone. + +To connect: please reach out in the #slack-admins channel, mention one of us in the specific channel where you have a question, or DM (Direct Message) one of us privately. + +### ADMIN EXPECTATIONS AND GUIDELINES +* Adhere to Code of Conduct +* Take care of spam as soon as possible, which may mean taking action by making members inactive +* Moderating and fostering a safe environment for conversations +* Bring Code of Conduct issues to the Steering Committee +* Create relevant channels and list Code of Conduct in new channel welcome message +* Help troubleshoot Slack issues +* Review bot, token, and webhook requests +* Be helpful! + +## CREATING CHANNELS +Please reach out to the #slack-admins group with your request to create a new channel. + +Channels are dedicated to [SIGs, WGs](/sig-list.md), sub-projects, community topics, and related Kubernetes programs/projects. +Channels are not: +* company specific; cloud providers are ok with product names as the channel. Discourse will be about Kubernetes-related topics and not proprietary information of the provider. +* private unless there is an exception: code of conduct matters, mentoring, security/vulnerabilities, or steering committee. + +Typical naming conventions: +#kubernetes-foo #sig-foo #meetup-foo #location-users #projectname + +All channels need a documented purpose. Use this space to welcome the targeted community: promote your meetings, post agendas, etc. + +We may make special accommodations where necessary. + +## ESCALATING and/or REPORTING A PROBLEM +Join the #slack-admins channel or contact one of the admins in the closest timezone via DM directly and describe the situation. If the issue can be documented, please take a screenshot to include in your message. + +What if you have a problem with an admin? +Send a DM to another listed Admin and describe the situation OR +If it’s a code of conduct issue, please send an email to steering-private@kubernetes.io and describe the situation + +## BOTS, TOKENS, WEBHOOKS, OH MY + +Bots, tokens, and webhooks are reviewed on a case-by-case basis with most requests being rejected due to security, privacy, and usability concerns.. Bots and the like tend to make a lot of noise in channels. Our Slack instance has over 30,000 people and we want everyone to have a great experience. Please join #Slack-admins and have a discussion about your request before requesting the access. GitHub workflow alerts into certain channels and requests from CNCF are typically OK. + +## ADMIN MODERATION +Be mindful of how you handle communication during stressful interactions. Administrators act as direct representatives of the community, and need to maintain a very high level of professionalism at all times. If you feel too involved in the situation to maintain impartiality or professionalism, that’s a great time to enlist the help of another admin. + +Try to take any situations that involve upset or angry members to DM or video chat. Please document these interactions for other Slack admins to review. + +Content will be automatically removed if it violates code of conduct or is a sales pitch. Admins will take a screenshot of such behavior in order to document the situation. The community takes such violations extremely seriously, and they will be handled swiftly. + +## INACTIVATING ACCOUNTS + +For reasons listed below, admins may inactivate individual Slack accounts. Due to Slack’s framework, it does not allow for an account to be banned or suspended in the traditional sense. [Visit Slack’s policy on this.](https://get.Slack.help/hc/en-us/articles/204475027-Deactivate-a-member-s-account) + +* Spreading spam content in DMs and/or channels +* Not adhering to the code of conduct set forth in DMs and/or channels +* Overtly selling products, related or unrelated to Kubernetes + +## SPECIFIC CHANNEL RULES + +In the case that certain channels have rules or guidelines, they will be listed in the purpose or pinned docs of that channel. + +#kubernetes-dev = questions and discourse around upstream contributions and development to kubernetes +#kubernetes-careers = job openings for positions working with/on/around Kubernetes. Postings should include contact details. + +## DM (Direct Message) Conversations + +Please do not engage in proprietary company specific conversations in the Kubernetes Slack instance. This is meant for conversations around related Kubernetes open source topics and community. Proprietary conversations should occur in your company Slack and/or communication platforms. As with all communication, please be mindful of appropriateness, professionalism, and applicability to the Kubernetes community. diff --git a/community/2016-events/Kubernetes_1st_Bday.md b/community/2016-events/Kubernetes_1st_Bday.md deleted file mode 100644 index 58290215..00000000 --- a/community/2016-events/Kubernetes_1st_Bday.md +++ /dev/null @@ -1,23 +0,0 @@ -# Kubernetes 1st Birthday Announcement - -Dear Kubernauts, - -Happy birthday! The Kubernetes community is celebrating the first anniversary for the v1.0 release on July 21st, 2016. We are reaching out to you as the chief point(s) of contact for your local Kubernetes meetup to encourage you to throw a Kubernetes birthday party! - -This is very exciting for the Kubernetes community, and we are happy to support your party planning efforts. We have swag we can provide (including awesome Kubernetes party hats!) and we will do our best to support your other endeavors. - -Since the actual anniversary is on July 21st, that date will likely be receiving the majority of the press and social media attention. But, by no means do you need to force your meetup to happen on July 21st; any time in late July or early August works great! We’re just hoping to get more people excited about Kubernetes and get users and developers meeting across the world. - -You may additionally be interested in joining the [Kubernetes Meetup leads mailing list](https://groups.google.com/forum/#!members/kubernetes-meetup-leads) where you can meet other organizers and swap tips. The [CNCF](https://cncf.io/community) is also working with Kubernetes meetups to offer support for things like Meetup.com fees and events, including financial support up to $250 for some official meetups. For more information on that effort, you can contact [Chris Aniszczyk](mailto:caniszczyk@linuxfoundation.org) and [Brett Preston](mailto:bpreston@linuxfoundation.org). - -Please contact us via [this Google form](https://docs.google.com/forms/d/1B17ckkz-FYEFhkQ2ZD8PZBH1ZnSCdpS366lB3a6MAtE/viewform) with any questions / requests / suggestions for your meetup. Alternatively, you can reach out to us directly (czahedi@google.com and sarahnovotny@google.com). We hope to hear from you soon! - -Lastly, if you know other people working with Kubernetes, please send this invitation their way! It could be a great chance for them to plug into a Meetup.com group or the mailing list above. - -And lest we forget, I’m Cameron Zahedi. I’ll be working with Sarah on her Kubernetes community endeavors, and I’m happy to help (or find the right person to help!) wherever possible. - -Cheers, - -Cameron and Sarah (on behalf of the Kubernetes Community.) - - diff --git a/community/2016-events/developer-summit-2016/KubDevSummitVoting.md b/community/2016-events/developer-summit-2016/KubDevSummitVoting.md deleted file mode 100644 index 46909c02..00000000 --- a/community/2016-events/developer-summit-2016/KubDevSummitVoting.md +++ /dev/null @@ -1,33 +0,0 @@ -###Kubernetes Developer's Summit Discussion Topics Voting -### -A voting poll for discussion topic proposals has been created, and the link to the poll can be found [here][poll]. - -The poll will close on 10/07/16 at 23:59:59 PDT. - -#### How Does it Work? -#### -The voting uses the Condorcet method, which relies on relative rankings to pick winners. You can read more about the Condorcet method and the voting service we're using on the [CIVS website][civs]. - -There are 27 topics to choose from, and you will rank them from 1 (favorite) to 27 (least favorite). You can also mark "no opinion" on topics that you don't wish to include in the ranking. - -The poll on CIVS has just the topic titles for ease of viewing. For topic descriptions, please see this [spreadsheet][topics]. The topic order on the voting service should mirror the order on the spreadsheet. - -You will note the message saying "*Only the 15 favorite choices will win the poll*". CIVS requires a number be selected for winners, and we have arbitrarily chosen 15. The final schedule may include more or less than 15 of the submitted topics. - -##### A Small Request -##### - -In order to make the poll accessible via URL, it has to be made "public". This means than any unique IP address can vote, which can be easily exploited for multiple votes. - -We fully expect the community to behave with sportsmanship and only vote once, and as such we almost didn't bring this concern up to begin with. However, we have chosen to explicitly address it, in order to reiterate the importance of everyone's voice receiving equal weight in a community-driven event. - -#### After the Poll -#### -A schedule will be made from the winning topics with -some editorial license, and the schedule will be announced to the group -at least a week before the event. - -[//]: # (Reference Links) - [civs]: - [poll]: - [topics]: \ No newline at end of file diff --git a/community/2016-events/developer-summit-2016/Kubernetes_Dev_Summit.md b/community/2016-events/developer-summit-2016/Kubernetes_Dev_Summit.md deleted file mode 100644 index f66df508..00000000 --- a/community/2016-events/developer-summit-2016/Kubernetes_Dev_Summit.md +++ /dev/null @@ -1,96 +0,0 @@ -# Kubernetes Dev Summit -# - -## Edit - Event Location -## -The event is on the 4th Floor of the *Union Street Tower* of the Sheraton Seattle Hotel. - -# About the Event -# -The Kubernetes Developers' Summit provides an avenue for Kubernetes -developers to connect face to face and mindshare about future community -development and community governance endeavors. - -In some sense, the summit is a real-life extension of the community -meetings and SIG meetings. - -## Event Format -## -The Dev Summit is a "loosely-structured [unconference][uncf]". Rather -than speakers and presentations, we will have moderators/facilitators -and discussion topics, alongside all-day completely unstructured -hacking. - -The discussion sessions will be in an open fishbowl format — rings of -chairs, with inner rings driving the discussion — where anyone can -contribute. The various sessions will be proposed and voted on by the -community in the weeks leading up to the event. This allows the -community to motivate the events of the day without dedicating precious -day-of time to choosing the sessions and making a schedule. - -There will be 3 rooms dedicated to these sessions running in parallel -all day. Each session should last between 45 minutes and an hour. - -Then, there will be 2 smaller rooms for hacking / unstructured -discussion all day. - -#### Who Should Go? -#### -The target audience is the Kubernetes developer community. The group -will be relatively small (~120-150 attendees), to improve communication -and facilitate easier decision-making. The majority of the attendees -will be selected from key company team and SIG leaders, power-users, and -the most active contributors. An additional pool of tickets will be -awarded via lottery. **Any interested party** should enter the lottery via -[this form][lotfrm]. Invitees will receive an invitation on or before October 12th. -RSVP information will be available in the invitation email. Tickets are -not transferrable. - -Please note that this Summit is not the right environment for people to -*start* learning about the Kubernetes project. There are plenty of -[meetups][mtp] organized by global user groups where one can get -involved initially. - -#### Call for Proposals -#### -Proposals for discussion topics can be submitted through [this -form][propfrm] by September 30, 23:59 PT. If you propose a session topic, -please be prepared to attend and facilitate the session if it gets -chosen. Other members will help with moderating, either as volunteer -co-facilitators or as members of the larger discussion group. - -Suggestions for session topic themes: - -* Hashing out technical issues -* Long term component / SIG planning - -In early October, proposal topics will be posted to the kubernetes-dev -mailing list and voted on via [CIVS][civs], the Condorcet Internet -Voting Service. A schedule will be made from the winning topics with -some editorial license, and the schedule will be announced to the group -at least a week before the event. - -## When & Where? -## -The Dev Summit will follow [Kubecon][kbc] on November 10th, 2016. -Fortunately for those who attend Kubecon, the Dev Summit will be at the -same venue, [the Sheraton Seattle Hotel][sher]. As of now, the day's -activities should run from breakfast being served at 8 AM to closing -remarks ending around 3:30 PM, with an external happy hour to follow. - -## Desired outcomes -## -* Generate notes from the sessions to feed the project's documentation -and knowledge base, and also to keep non-attendees plugged in -* Make (and document) recommendations and decisions for the near-term and -mid-term future of the project -* Come up with upcoming action items, as well as leaders for those action items, for the various topics that we discuss - -[//]: # (Reference Links) - [uncf]: - [mtp]: - [lotfrm]: - [propfrm]: - [civs]: - [kbc]: - [sher]: diff --git a/community/2016-events/developer-summit-2016/application_service_definition_notes.md b/community/2016-events/developer-summit-2016/application_service_definition_notes.md deleted file mode 100644 index e8f4c0c5..00000000 --- a/community/2016-events/developer-summit-2016/application_service_definition_notes.md +++ /dev/null @@ -1,48 +0,0 @@ -# Service/Application Definition - -We think we need to help out the developers in how do we organize our services and how do I define them nicely and deploy on our orchestrator of choice. Writing the Kube files is a steep learning curve. So can we have something which is a little bit easier? - -Helm solves one purpose for this. - -Helm contrib: one of the things folks as us is they start from a dockerfile, and they want to have a workflow where they go from dockerfile-->imagebuild-->registry-->resource def. - -There are different ways to package applications. There's the potential for a lot of fragmentation in multi-pod application definitions. Can we create standards here? - -We want to build and generate manifests with one tool. We want "fun in five" that is have it up and running in five minutes or less. - -Another issue is testing mode; currently production-quality Helm charts don't really work on minikube,. There's some issues around this which we know about. We need dummy PVCs, LoadBalancer, etc. Also DNS and Ingress. - -We need the 80% case, Fabric8 is a good example of this. We need a good set of boundary conditions so that the new definition doesn't get bigger than the Kube implementation. Affinity/placement is a good example of "other 20%". - -We also need to look at how to get developer feedback on this so that we're building what they need. Pradeepto did a comparison of Kompose vs. Docker Compose for simplicity/usability. - -One of the things we're discussing the Kompose API. We want to get rid of this and supply something which people can use directly with kuberntes. A bunch of shops only have developers. Someone asked though what's so complicated with Kube definitions. Have we identified what gives people trouble with this? We push too many concepts on developers too quickly. We want some high-level abstract types which represent the 95% use case. Then we could decompose these to the real types. - -What's the gap between compose files and the goal? As an example, say you want to run a webserver pod. You have to deal with ingress, and service, and replication controller, and a bunch of other things. What's the equivalent of "docker run" which is easy to get. The critical thing is how fast you can learn it. - -We also need to have reversability so that if you use compose you don't have to edit the kube config after deployment, you can still use the simple concepts. The context of the chart needs to not be lost. - -There was discussion of templating applications. Person argued that it's really a type system. Erin suggested that it's more like a personal template, like the car seat configuration. - -There's a need to let developers work on "their machine" using the same spec. Looking through docker-compose, it's about what developers want, not what kubernetes wants. This needs to focus on what developers know, not the kube objects. - -Someone argued that if we use deployments it's really not that complex. We probably use too much complexity in our examples. But if we want to do better than docker-compose, what does it look like? Having difficulty imagining what that is. - -Maybe the best approach is to create a list of what we need for "what is my app" and compare it with current deployment files. - -There was a lot of discussion of what this looks like. - -Is this different from what the PAASes already do? It's not that different, we want something to work with core kubernetes, and also PAASes are opinionated in different ways. - -Being able to view an application as a single unifying concept is a major desire. Want to click "my app" and see all of the objects associated with it. It would be an overlay on top of Kubernetes, not something in core. - -One pending feature is that you can't look up different types of controllers in the API, that's going to be fixed. Another one is that we can't trace the dependencies; helm doesn't label all of the components deployed with the app. - -Need to identify things which are missing in core kubernetes, if there are any. - -## Action Items: - -* Reduce the verbosity of injecting configmaps. We want to simplify the main kubernetes API. For example, there should be a way to map all variables to ENV as one statement. -* Document where things are hard to understand with deployments. -* Document where things don't work with minikube and deployments. -* Document what's the path from minecraft.jar to running it on a kubernetes cluster? diff --git a/community/2016-events/developer-summit-2016/cluster_federation_notes.md b/community/2016-events/developer-summit-2016/cluster_federation_notes.md deleted file mode 100644 index 362cbafe..00000000 --- a/community/2016-events/developer-summit-2016/cluster_federation_notes.md +++ /dev/null @@ -1,21 +0,0 @@ -# Cluster Federation - -There's a whole bunch of reasons why federation is interesting. There's HA, there's geographic locality, there's just managing very large clusters. Use cases: - -* HA -* Hybrid Cloud -* Geo/latency -* Scalability (many large clusters instead of one gigantic one) -* visibility of multiple clusters - -You don't actually need federation for geo-location now, but it helps. The mental model for this is kind of like Amazon AZ or Google zones. Sometimes we don't care where a resource is but sometimes we do. Sometimes you want specific policy control, like regulatory constraints about what can run where. - -From the enterprise point of view, central IT is in control and knowledge of where stuff gets deployed. Bob thinks it would be a very bad idea for us to try to solve complex policy ideas and enable them, it's a tar pit. We should just have the primitives of having different regions and be able to say what goes where. - -Currently, you either do node labelling which ends up being complex and dependent on discipline. Or you have different clusters and you don't have common namespaces. Some discussion of Intel proposal for cluster metadata. - -Bob's mental model is AWS regions and AZs. For example, if we're building a big cassandra cluster, and you want to make sure that nodes aren't all in the same zone. - -Quinton went over a WIP implementation for applying policies, with a tool which applies policy before resource requests go to the scheduler. It uses an open-source policy language, and labels on the request. - -Notes interrupted here, hopefully other members will fill in. diff --git a/community/2016-events/developer-summit-2016/cluster_lifecycle_notes.md b/community/2016-events/developer-summit-2016/cluster_lifecycle_notes.md deleted file mode 100644 index f42df9f6..00000000 --- a/community/2016-events/developer-summit-2016/cluster_lifecycle_notes.md +++ /dev/null @@ -1,132 +0,0 @@ -# Cluster Lifecycle Deployment & Upgrade Roadmap - -Moderator: Mike Danese - -Note taker: Robert Bailey - -Date: 2016-11-10 - -## Goals - -Discuss HA, upgrades, and config management beyond kubeadm/kops & try to identify things that are currently underserved (upgrade testing, version skew policy, security upgrades) - -## Discussion - -kubeadm - not destined for production? -* Doing resource provisioning (cloud VMs) is out of scope -* Should be a toolbox that does the common parts of cluster lifecycle - * And should be able to break out just the pieces that you want -* Found a bunch of common parts of existing cluster deployment and want to build more of it into the core - -AI (luke): Create an intro guide to cluster lifecyle - -If anyone wants to work on Upgrades the Hard Way with Rob this afternoon. - -Wishlist -* HA -* Upgrades -* Config Management -* Toolbox vs. guided flow -* Documentation -* Conformance Testing -* PKI - -### HA - -* Story hasn't changed in a long time: - * People set up the cluster, run them in production - * Lack of documentation -* What haven't we been focused on? - * Some day there may be apiservers that may move, but there aren't today - * If you've misconfigure it, it's really hard to debug - * E.g. If you just launch 2 apiservers they fight over the endpoint. It requires insider knowledge to recognize this and know how to fix it - * Forces an ip address on the endpoint, which isn't compatible with AWS - * AI (claytonc): Fix the flag to take a host instead of just an ip address -* There are things that are command line flags that are going to be a pain to synchronize - * Move more configuration into etcd - -### Upgrades - -* Minor and patch upgrades, look at them separately -* Do we have skew requirements that are different for minor vs patch upgrades? - * E.g. Can you upgrade nodes before master for a patch version? -* AI: Socialize the existing version skew documentation -* AI: Clarify the documentation skew -* Do we want to support 4-part version numbers? - * Chris love: please don't do this -* Mike Rubin: Patch releases shouldn't create surprises -* Distribution of Kubernetes? -* Jordan Liggitt: Would like to see upgrade documentation on every install guide - * At least for patch releases - * AI (?): File issues against owners for the current getting started guides to add a section on upgrades -* Luke Marsden: I would like to lead an effort to support self hosting in some of the user flows (in particular a kubeadm flow) in an attempt to make it really easy to deploy a patch upgrade - * Assume single master, external etcd - * Joe Beda: The nice thing about self hosting upgrades is that there isn't anything cloud platform specific which allows us to build more general tooling - -### Distribution - -* In 1.5 we've begun experimenting with OS package management tooling -* Should we push further on this? -* The release tarball is getting bigger - * Should be ameliorated in 1.5 by breaking it into arch-specific bundles -* Jordan Liggitt: We can't tell people to script their install against the tarball because the structure of the tarball becomes an api - -### Config Management - -* Config is currently command line flags. Work is being done to convert into structured api types (outstanding PRs from ncdc@ and mtoffen@). -* How much should we use config maps vs flags vs something else? -* Joe Beda: Definitely an issue for the kubelet - specifically setting the DNS IP flag - * Vish: Unless/until the kubelet has local checkpointing it's dangerous to use the apiserver for checkpointing configuration since the apiserver may become unavailable -* Need to figure out how we deal with config that points to other files (e.g. certs) -* Rob: We may want to split the discussion about configuring the kubelet vs the control plane -* Mike Rubin: The kubelet will eventually need to be able to run standalone. Need to think about packaging and configuration as distinct. - * The Kubelet has a lot of value if it can work without an apiserver - * The node effort takes Docker + Linux and productizes it -* Mike Danese: The same type of config could also benefit other components -* Jordan Liggitt: Have client cert bootstrap stuff in Kubelet - -### Toolbox vs guided flow - -* [mostly skipped for time] -* Chris Love: Need to document our compartmentelizing each thing -* Luke: This isn't a "vs" it's an "and" - -### Documentation - -* What is lacking? -* Joe Beda: The fact that Kelsey had to write "Kubernetes the hard way" shows that we don't have documentation -* Chris Love: HA Upgrades -* Jordan Liggitt: Docs should look like a tree - * Start at the high level, if you want more detail, then you can drill down into each piece - * If you expand to all of the leaves, then you end up back at k8s the hard way -* Mike Rubin: Questions from support/users are less about setting up and more about tearing down - * What will still be around after destroying a cluster - * E.g. Deleting a namespace, deleting a cluster from a federation, deleting a node from the cluster -* Need an introduction to the SIG (Luke already volunteered to write one) -* Mike Rubin: Rollbacks and rollback documentation - * When you add a new feature (say in 1.4) and we roll back to an earlier version what happens to those resources - * Chris Love: elephant is what happens when you roll back from etcd3 → etcd2 - -### Conformance Testing - -* What can we do in 2017 to make progress on this? -* Jordan Liggitt: Need to categorize conformance tests into ones that you could run against a production cluster vs those that you shouldn't -* Lucas: Three levels of validation: node, k8s standard base, deep/destructive testing. Want to make these all easy through kubeadm -* Is performance testing out of scope? - * Clayton: Misconfiguration is often caught through performance testing so we shouldn't remove it from scope - -### PKI - -* Jordan Liggitt: Have client cert bootstrap stuff in Kubelet -* Chris Love: Need to loop in sig-auth. Need to use TLS certs for etcd clusters. -* Aaron Levy: Plan to add CSR into the etcd operation similar to what is going into the k8s api. -* Joe Beda: Two modes right now: can have the apiserver act as a CA; many serious users will want to use their own CA -* Jordan Liggitt: Things that need certs should be able to take them or components should be able to generate (if appropriate) - * Rotation depends on whether we are using the built-in CA or an external CA -* Mike Rubin: Why not do both rotation and revocation - * Rob: Many applications don't respect revocation so it's generally considered weaker -* Clayton: If you can rotate then you may not need to revoke -* Jordan Liggitt: Tied to config management -* Joe Beda: Part of the discovery info is the root CA and many people don't realize that it can be a bundle instead of a single CA — this enables rotation -* Clayton: In a secured cluster, etcd is the core. Have to think about it as the inner circle of security that the apiserver is outside of. If you are extremely cautious then you should use client certs in the apiserver. You can collapse the rings if you want. - diff --git a/community/2016-events/developer-summit-2016/k8sDevSummitSchedule.pdf b/community/2016-events/developer-summit-2016/k8sDevSummitSchedule.pdf deleted file mode 100644 index 6cd8d01b..00000000 Binary files a/community/2016-events/developer-summit-2016/k8sDevSummitSchedule.pdf and /dev/null differ diff --git a/community/2016-events/developer-summit-2016/statefulset_notes.md b/community/2016-events/developer-summit-2016/statefulset_notes.md deleted file mode 100644 index d019d256..00000000 --- a/community/2016-events/developer-summit-2016/statefulset_notes.md +++ /dev/null @@ -1,38 +0,0 @@ -# StatefulSets Session - -Topics to talk about: -* local volumes -* requests for the storage sig -* reclaim policies -* Filtering APIs for scheduler -* Data locality -* State of the StateFulSet -* Portable IPs -* Sticky Regions -* Renaming Pods - -## State of the StatefulSet - -1.5 will come out soon, we'll go beta for StatefulSets in that one. One of the questions is what are the next steps for Statefulsets? One thing is a long beta, so that we know we can trust statefulsets and they're safe. - -Missed some discussion here about force deletion. - -The pod isn't done until the kubelet says it's done. The issue is what happens when we have a netsplit, because the master doesn't know what's happening with the pods. In the future we'll maybe add some kind of fencer to make sure that they can't rejoin. Fencing is probably a topic for the Bare-Metal Sig. - -Are we going to sacrifice availability for consistency? We won't explicitly take actions which aren't safe automatically. Question: should the kubelet delete automatically if it can't contact the master? No, because it can't contact the master to say it did it. - -When are we going to finish the rename from PetSet to StatefulSet? The PR is merged for renaming, but the documentation changes aren't. - -Storage provisioning? The assumption is that you will be able to preallocate a lot of storage for dynamic storage so that you can stamp out PVCs. If dynamic volumes aren't simple to use this is a lot more annoying. - -Building initial quorums issue? - -It would be great to have a developer storage class which ties back to a fake NFS. For testing and dev. The idea behind local volumes is that it should be easy to create throwaway storage on local disk. So that you can write things which run on every kube cluster. - -Will there be a API for the application? To communicate members joining and leaving. Answer today is that's what the KubeAPI is for. - -The hard problem is configchange. You can't do config change unless you bootstrap it correctly. If kube is changing things under me I can't maintant quorum (as an app). This happens when expanding the set of nodes. You need to figure out who's in and who's out. - -Where does the glue software which relates the statefulset to the application? But different applications handle things like consensus and quorum very differently. What about notifying the service that you're available for traffic. Example for this with etcd with readiness vs. membership service. You can have two states, one where the node is ready, and one where the application is ready. Readiness vs. liveness check could differentiate? - -Is rapid spin-up a real issue? Nobody thinks so, diff --git a/community/2016-events/fixit201606.md b/community/2016-events/fixit201606.md deleted file mode 100644 index f7d43641..00000000 --- a/community/2016-events/fixit201606.md +++ /dev/null @@ -1,61 +0,0 @@ -#Fixit Event June 2016 - -Google runs internal fixit weeks. During these weeks the teams set aside all critical deadlines, showstopper bugs, regular development -- everything -- to pull together to achieve a common goal. And, we invite the Kubernetes community to join the June 2016 fixit. - -Please take a look at anything that is [kind/flake] (https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Akind%2Fflake%20) or, with our 1.4 focus on "mean time to dopamine" for our users, help [team/ux] (https://github.com/kubernetes/kubernetes/labels/team%2Fux) or spend time triaging, de-duplicating, or closing issues that were [opened before 20160101] (https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=created%3A%3C2016-01-01%20state%3Aopen%20) or check out the [issues in our docs] (https://github.com/kubernetes/kubernetes.github.io/issues) repository. All of these avenues will help Kubernetes improve the user and developer experiences with the project. - -Another important piece of fixit culture is rewards. **Everyone who contributes (as measured by engagements on Github) between 6/27 and 7/1 will receive Kubernetes stickers and all merged PRs that are contributed during the fixit will will receive a Kubernetes embroidered patch.** - -#But, wait, there's more! - -Since improvement isn't only about code and issues, we'd like to also help grow our community skills. And, to that end, below is a schedule of some interesting content and community events. - -The community meeting calendar is [available as an iCal] -(https://calendar.google.com/calendar/ical/cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com/public/basic.ics) -to subscribe to (simply copy and paste the url into any calendar -product that supports the iCal format) or [html to view] -(https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). -All sessions listed below are listed on the community calendar and -will be broadcast on the [community meeting URL] -(https://zoom.us/my/kubernetescommunity). - -##Tuesday 05:00 PT - -**Office Hours - Filip Grzadkowski [Recording] (https://www.youtube.com/watch?v=nKHYnvTr7LE)** - -K8s developers to hold office hours over VC where we ask members of the community to bring questions about how the system works. - -##Thursday 10:00 PT - -**Community Meeting - Usual Suspects [Recording] (https://www.youtube.com/watch?v=gv3yMQ_F4_k)** - -The usual get together full of demos, discussions, and yummy yummy information. - -##Thursday 11:00 PT - -**Office Hours - Vishnu Kannan [Recording] (https://www.youtube.com/watch?v=v_WI4P1ZEEQ)** - -K8s developers to hold office hours over VC where we ask members of the community to bring questions about how the system works. - -##Friday 10:00 PT - -**1.3 Release Community Postmortem - Jason Singer Dumars [Recording] (https://youtu.be/kqKW7QLlwAA)** - -Following the release of 1.3 this is an opportunity to share what went well, what went poorly and discuss how we want to improve the development and release of 1.4. - -##To be rescheduled. - -**A live debugging session. -- Janet Kuo** - -It's possible to learn so much while watching others debug. One of our team members will debug a problem during a video session. They will show the community tricks and informal techniques required to solve problems live. - -#Metrics - -For those of you who are tracking our progress... - -[Issues and PRs closed >2016-06-27] (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+closed%3A%3E2016-06-27+&type=Issues&ref=searchresults) - -[Issues created and still open >2016-06-27] (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+created%3A%3E2016-06-27+is%3Aopen&type=Issues&ref=searchresults) - -Alternately, [counting only closed issues] (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+closed%3A%3E2016-06-27+is%3Aissue&type=Issues&ref=searchresults) - diff --git a/community/2017-events/05-leadership-summit/announcement.md b/community/2017-events/05-leadership-summit/announcement.md deleted file mode 100644 index 4417a910..00000000 --- a/community/2017-events/05-leadership-summit/announcement.md +++ /dev/null @@ -1,26 +0,0 @@ -This is an announcement for the 2017 Kubernetes Leadership Summit, which will occur on June 2nd, 2017 in San Jose, CA. -This event will be similar to the [Kubernetes Developer's Summit](/community/2016-events/developer-summit-2016/Kubernetes_Dev_Summit.md) in November -2016, but involving a smaller smaller audience comprised solely of leaders and influencers of the community. These leaders and -influences include the SIG leads, release managers, and representatives from several companies, including (but not limited to) -Google, Red Hat, CoreOS, WeaveWorks, Deis, and Mirantis. - -The summit will provide an avenue for leaders in the Kubernetes community to connect face to face and mindshare about future -community development and community governance endeavors. - -This announcement serves to notify the broader community of the existence and goals of the event. - -This is an **invite-only event**. All invitees will receive a direct invitation from Cameron (czahedi *at* google *dot* com). - -### Event Format - -The Leadership Summit will mirror the format of the Developer’s Summit, which was a "loosely-structured unconference”. We will have moderators/facilitators and discussion topics, alongside all-day completely unstructured / spontaneous breakouts. - -The various sessions will be proposed and voted on by the community in the weeks leading up to the event. This allows the -community to motivate the events of the day without dedicating precious day-of time to choosing the sessions and making a -schedule. - -### Desired outcomes - -* Generate notes from the sessions to feed the project's documentation and knowledge base, and also to keep non-attendees plugged in -* Make (and document) recommendations and decisions for the near-term and mid-term future of the project -* Come up with upcoming action items, as well as leaders for those action items, for the various topics that we discuss diff --git a/community/2017-events/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md b/community/2017-events/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md deleted file mode 100644 index a6fa64de..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md +++ /dev/null @@ -1,198 +0,0 @@ -# Code Organization and Release Process Improvement - -**Identify the following before beginning your session. Do note move forward until these are decided / assigned: ** - -- **Session Topic**: Code Organization and Release Process Improvement -- **Topic Facilitator(s)**: bgrant0607@ -- **Note-taker(s) (Collaborating on this doc)**: jdumars@ -- **Person responsible for converting to Markdown & uploading to Github:** michellen@ - -### Session Notes - -#### Background from November dev summit: -- [Slides](https://docs.google.com/presentation/d/1SD6a6eJl47t0qyTFE8GzaiytW4T_crdWgYAMCaLy1W8/edit#slide=id.g18ae10430d_0_7) -- [Notes](https://www.google.com/url?q=https://docs.google.com/document/d/1zN2DWKerXwbzxZTO52wBRqp_uHMdLp8P52xYOmp5WZ4/edit&sa=D&ust=1496186064062000&usg=AFQjCNG8Z-9KBJJkUsQY9F38CdZY3Nc_LA) - -#### Github orgs: -Github supports 2 levels of hierarchy, orgs and repos, and we need to use both effectively. We need to move away from monorepos, such as kubernetes/kubernetes and kubernetes/contrib, and mono-orgs, such as kubernetes and kubernetes-incubator. [Kubernetes-client](https://github.com/kubernetes-client) is the first focused org. - -Ideally, code would be divided along lines of ownership, by SIG and subproject, with infrastructure for packaging the code (APIs and controllers) into the desired number of components (e.g., hyperkube as well as factored by [layer](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.p)) and releases (e.g., [monthly](https://github.com/kubernetes/community/issues/567) as well as LTS). - - -#### Where we are on multiple repos: -* [Code organization issue](https://github.com/kubernetes/kubernetes/issues/4851) -* [kubernetes multi-repo issue](https://github.com/kubernetes/kubernetes/issues/24343) and [contrib](https://github.com/kubernetes/contrib/issues/762) breakup issue -* User docs were moved to kubernetes/kubernetes.github.io -* Contributor docs were moved to kubernetes/community -* Examples have been copied to kubernetes/examples, but haven’t yet been removed from the kubernetes repo -* [API machinery](https://github.com/kubernetes/kubernetes/issues/2742): In order to build virtually anything outside the kubernetes repo, the API machinery needs to be made available, for component configuration, for building APIs, for building controllers and other Go clients of the APIs, etc. - * Staging - * [Client-go](https://github.com/kubernetes/kubernetes/issues/41629) - * [API types](https://github.com/kubernetes/kubernetes/pull/44784), will be done during 1.7 code freeze -* TODO: util - * pkg/util moves thread -* Kubectl: - * In the process of breaking kubectl <-> kubernetes dependencies - * Have kubernetes/kubectl repo, need to migrate issues there - * Issue migration tool exists - creates lots of notifications - -Next up: -* [kubeadm](https://github.com/kubernetes/kubernetes/issues/35314) -* Federation -* [cloudprovider](https://git.k8s.io/kubernetes/pkg/cloudprovider/README.md) and [cluster](https://git.k8s.io/kubernetes/cluster/README.md) -* Scheduler -* [Kubelet](https://github.com/kubernetes/kubernetes/issues/444) - -#### Build system and checking in generated code (or not): -* [Issue about not checking in generated code](https://github.com/kubernetes/kubernetes/issues/8830) -* [Nuke Ugorji](https://github.com/kubernetes/kubernetes/issues/36120) -* [Update and verify script thread](https://groups.google.com/d/msg/kubernetes-dev/5rVmSJqCq-U/tyN8OVRjBgAJ) -TODO: Bazel, make - -#### Vendoring: -What would be better than godeps? Dep? Glide? -[https://github.com/kubernetes/kubernetes/issues/44873](https://github.com/kubernetes/kubernetes/issues/44873) - -#### Other: -* Client and [client tool](https://github.com/kubernetes/release/issues/3) releases -* More unit tests rather than end-to-end tests -* [Feature branches](https://github.com/kubernetes/community/issues/566) - -#### Multi-repo requirements - -#### Release process -* Components are combined from subrepos to build released bits -* Components each have sufficient testing against their repo to determine if they are stable to release - -#### Development process in multiple repos -* PRs sent to external repos -* PR and CI tests run against external repo. Sufficient to validate the code maybe released as a component. - * Unit + Integration tests - * e2e tests? -* Automatically update vendored deps from consuming repos -* e2e tests run against main repo against integrated components - -#### Process to move code into its own repo - -#### Considerations -* Does the code depend on kubernetes/kubernetes code? - * Break these dependencies or move the deps to another repo -* Does other code from kubernetes/kubernetes depend on the code? - * Must update package names -* Can code be fully tested independent of kubernetes/kubernetes code? -* Will the code share the same release as kubernetes/kubernetes or be released independently? - * Clients released independently need a way to perform version skew testing - -#### Possible workflow -* Maybe first move to “staging” directory to simulate multi-repo within single repo - this has its own costs -* Remove cyclic dependencies between repositories -* Update mungebot to close PRs that update moved packages -* Copy code to new location -* Vendor code from new location to main repo (if needed) -* Change package names to the vendored code -* Delete old code - -Where do we need to get to in order to separate: [ [diagram](https://files.slack.com/files-tmb/T09NY5SBT-F5NU1FPPG-0bb64d7351/image_uploaded_from_ios_1024.jpg) ] -* Utility packages need to go somewhere -* API packages need to move -* Helper libraries (reusable server infrastructure) -* Code generators - -Consumer-visible -* client go -* kubectl - -Need to get the API types into their own repo -* currently have a staging area, and a copy/paste script -Need to develop in those repos and then assemble a coherent release from them - -re: kubectl moving, -* 1. sits in the repo but build rules break bad dependencies, can start shipping it independently -* 2. make sure everything still works - -kubectl could get its own release - -build files to add visibility - -kubectl should never be imported - -As these refactors happen, Brian Grant will be more lenient with privileges, establishing janitors - -kubectl split is technical debt cleanup - testing should not rely on e2e, no compiled-in dependencies - -breaking the dependencies yields more benefits - -Q: Will kubectl be buildable with go get? -A: Probably, but definitely with bazel - -Integration testing plan? -Use last stable release in k/k e2e tests - -We need to catch regressions when it’s being released, not when it’s vendored back in - -Need better, smaller tests overall - -kops has a blocking PR test - kops master + what is in your PR - -cross-component problems at the main level - -Need a central build pipe in order to untangle dependencies - -Experience breaking apart has been negative as a contributor - -Q: What is the contribx? Testing? -A: Short term will be many separate PRs, need to solve dependencies in test management - -Please do not add new binaries in the kubernetes repo - -Need help -* getting rid of generated code -* build system -* solve vendoring problem - -Working group? Code health WG - -Client tool SDK? - -kubectl -> SIG CLI -code -> API Machinery - -Caution against validating undocumented functionality via CI, better: documentation and integration test as a validation ~ API testing - -Too much testing is currently e2e - -Don’t make a catchall util package - -### Conclusions - -#### Key Takeaways / Analysis of Situation -#### Recommendations & Decisions Moving Forward (High-Level) - -Should build and release be the same SIG? Where does build live? -- SIG release / SIG testing - -Q: Is it worthwhile to go through the project and specify what needs to be moved out? -A: In the SIG assignment process there may be breakup - - -Action Item |Owner(s) -------------|------------ -Need a SIG owner on utilities | Tim Hockin -Talk to Cloud Foundry and see how they do it | Caleb at Community -Working group organization or a SIG that oversees this | Machinery, CLI, Cluster Lifecycle -Regular community checkins | Brian Grant -Describe the end state and then assign breakout work to SIGs | Working group needs to be organized - Brian Grant - -#### Instructions -1. Make a copy of the “Template” area of this document in the folder. -2. Set the “Share” settings to be “anyone with the link can edit” and take your session notes there. Ensure to decide/assign (and document) the topic title, facilitator(s), note-taker(s), and Github uploader. -3. Later, convert the notes to Markdown and upload to this GitHub directory: -4. Save your session notes with the following format: - a. HHMM-HHMM_SESSIONTITLE.md - i. where HHMM is the time in 24-hour format in the PST zone. - - -#### Suggestions -* Use the document outline (Tools > Document Outline) and headings (Format > Paragraph Styles) to organize your notes as you go - - -[Link to original doc](https://docs.google.com/document/d/163JvzDIuBa4CzttxxG8tjYYPACQnD1DboW3BDG8VCUA/) 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 deleted file mode 100644 index 05287aad..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md +++ /dev/null @@ -1,108 +0,0 @@ -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 deleted file mode 100644 index 453b3931..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md +++ /dev/null @@ -1,81 +0,0 @@ -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 deleted file mode 100644 index 7e49baa8..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md +++ /dev/null @@ -1,98 +0,0 @@ -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 deleted file mode 100644 index 8349c40d..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md +++ /dev/null @@ -1,193 +0,0 @@ -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#) diff --git a/community/2017-events/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md b/community/2017-events/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md deleted file mode 100755 index 397c7c6a..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md +++ /dev/null @@ -1,107 +0,0 @@ -# SIG Governance and Check-in - -**Identify the following before beginning your session. Do not move forward until these are decided / assigned:** - -- **Session Topic: SIG Governance and check-in** -- **Topic Facilitator(s):** brendandburns@ -- **Note-taker(s) (Collaborating on this doc)**: jbeda@ -- **Person responsible for converting to Markdown & uploading to Github:** philips@ - -### Session Notes - -- Core discussions about SIG leadership - - Is the SIG lead role more like an on-call position or a team lead? - - There are 2 parts of the role: facilitation and management of the owners files - - authority comes from commits? - -#### Conclusions - -#### Key Takeaways / Analysis of Situation - -Recommendations & Decisions Moving Forward (High-Level) - -Specific Action Items (& Owners) - -| **Action Item** | **Owner(s)** | -| --- | --- | -| SIG starter kit: Gather constructive feedback from SIGs; Create a summary of that feedback | Bob Wise | -| How should SIG lead/governance work? Figure out a lot of this stuff. Everyone should share with the steering committee and get that ready for the full committee. | Steering Committee | -| Schedule SIG lead office hours to coordinate around PRs and getting stuff done. | Jason DuMars | -| SIG-architecture? | Steering Committee | -| SIG consolidation? | Steering Committee | - -#### Purpose - -- Michelle - - What is your format? - - How is it going? - - Are there things that you are struggling with? - - Do we need to formalize about forming/running/governing a SIG? -- Joe - - How do we pick SIG leads? What type of leadership? What are the responsibilities? Is this the same across the project or per SIG? - -#### Discussion - -- Rob: Cross cutting sig concerns? Venn diagram? Common concerns get lost. SIG-cloud is similar. -- What other types of horizontal/project? - - Ops, testing, etc. -- Bob: Would it be useful to draw connection map and formalize communication channels -- Eric: Staff and line position? Line = line of business. Staff = centralized responsibility. - - Q: Where would you put SIG-testing? A: staff? Testing guidance for all the SIGs. - - Technical area (LoB) vs. staff (shared service and expertise) -- Brendan -- there are technical staff groups vs. non-technical staff groups. Example testing vs. contrib-x. -- Joe: without some sort of automated mechanism that forces people to communicate it won't happen. Perhaps having the SIGs own code will force discussions at time of PR -- If we have a forcing function there requires more planning up front. Example is the rush to a release. -- Scrum of scrums? Have the leads get together and hash over that. - - Focus on visibility with accountability. -- Luke: perhaps have sig leads do offline sync ups? Bring in others as necessary. - - Vish: Sig leads may not know what is going on. - - Quinton: have identified people in the SIG that owns relationship with specific other SIGs. -- Bob: Getting better definition of what the sig lead job is would help. - - Make SIG-PM be made up of SIG-leads - - Brendan: SIG lead should be a thankless position. Very little power. Should be obligation. Somewhat like an on-call rotation vs. TL. -- Quinton: Is there a TL position? Who is driving the overall technical direction of an area. Separate from the lead position. - - Brendan: SIGs own directories. Approvers in those directories are TLs. - - Bob: current model SIG leads are volunteer thing and so it is optimistic to expect too much. Do we want to have elections. - - Brendan: worry about gaming with the openstack model wrt elections. - - Rob: in OpenStack -- SIGs were project groups. The usage of SIG to mean project is confusing. - - Eric: If people are going to be SIG leads -- too much power for too much responsibility. Should we solve by adding responsibility. - - Do sig leads have power now? It is mostly influence? - - **** Code vs. talk. - - Bob: You can say "code talks" but getting code in and earning that position can be super frustrating. "Code == influence" just isn't true right now. - - Adding code is easy. Reviewing code, curating tests, etc. That is the hard thing. -- What are the expectations to put on a SIG. Keep track of issue response times? -- Jason: What is the job of SIGs? How do we identify that and make sure it gets done? There isn't that one thing to test against. - - Leadership follows from this mission. - - Eric: As a governing board do we care how a sig does it as long as it does it well? I think the answer is we don't care. Doubts around template. - - Luke: That seems fine -- but we need to share what works and what goes poorly. - - Brendan: others said cross sig stuff is hard. Also poor communication across dependencies. - - What is success? Depends on the SIG. Lay out a plan and then accomplish it. - - SIG have obligations to release and own thing. Example is tests for that thing. Need to define interfaces -- Michelle: what are the best processes for governing and monitoring a SIG. What are the best processes? -- Aaron: Qs: Do SIG updates and recording help with communication. -- Joe: What we discussed through bootstrap is that we should have a starter kit for the SIGs; we don't really have strong opinions on how it actually works in practice though. -- Dalton: Clear lines of ownership for SIGs would be appreciated. Would welcome more guidance. SIG on-prem struggles with what they are responsible for today -- Challenge for horizontal SIGs include membership (especially technical) and influence. -- Brendan: focus on fewer larger SIGs. Not enough people with smaller SIGs. Consolidation may make things more efficient. -- Aaron: SIG updates at community seem to help tell what the SIGs are focusing on but it doesn't help on a week to week or release wide process. - - Does SIG-PM coordinate a snapshot of what is going on. But it isn't enough communication. - - Ihor: Almost meeting have reports from SIGs. -- How do we push people to write code in the right direction. What tools do we have to guide things. - - Hope from the steering committee is that if SIGs aren't doing something they should be doing there is an escalation. Example is SIG-testing is empowered to stop queue until things change. -- Joe: Eng reviews/SIG-architecture - - Advise to who and where to get sign off. - - Bob: alleviate frustrations that we had - -Lots of discussions on how to drive communication and when things get escalated. Help SIGs coordinate between themselves. - -Up to steering committee to help define what the requirements are on a SIG. Still unsure what that'll look like. - -Jason: rename SIG-lead to SIG-facilitator - -Good Practices - -Kind of like a starter kit for SIGs? Needed and recommended? - -- Notes and videos help -- Focusing bi-weekly for PRs vs. design discussion. diff --git a/community/2017-events/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md b/community/2017-events/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md deleted file mode 100644 index 865d4999..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md +++ /dev/null @@ -1,75 +0,0 @@ -# Community Building & Ladder Session - -_Original Title: “Building community effectiveness (Contributor ladder, Code of Conduct & Committee)”_ - -* Session Area: Community -* Topic Facilitator(s): Sarah Novotny -* Note-taker(s) (Collaborating on this doc): - * Rob Hirschfeld @zehicle - * Jess Frazzelle -* Person responsible for converting to Markdown & uploading to Github: Rob Hirschfeld @zehicle - -## Session Notes - -Classes of Communities being discussed: -* Developer / User - using the API -* Developer / Operator - running the Infrastructure / DevOps -* Developer / Contributor - writing the Kubernetes code, docs, any sort of non-technical contribution - -Topics/Conversation Thread: - -* Luke: How to get more people writing code in a sig, encourage new contributors to start contributing - * How sig leads can do a better job of encouraging contributors - * Defining contributions outside of code, people who plan face to faces, things that help build the community but are not necessarily limited to code -* Bob: contrib was declared dead, but if you are doing dev work in the community it is not clear where to put ideas out there for feedback - * Incubation bar is super high - * Things bigger than features, tools, etc -* Michael: talking about getting people involved without creating schedule risk - * There is a spreadsheet that people are using to track priorities of tasks - * Need to watch Shepherding bandwidth -* Sarah suggested that we need to make sure that reviewers are tagged as mentors also - * Helps people know who to ask for help, so they don’t stall -* Kris: it helps to get people to self-identify people’s interests in contributing -* Michael: use SIG meetings for status and encourage people to connect outside of meetings -* Jess: Suggested making sure to bring people in with an open item - * It helps to make introductions at the start of the meeting -* Kris - Bob: Office hours? Alternate weeks for the SIG -* Michael: Make sure to create a safe space - admit mistakes to be more inclusive -* Luke: there are a lot of people who are listening but not taking on work - -_Group discussed ways to get people to move into activity contributors_ - -* Sarah: hiring Community Manager role - first job will be to create a mentor pairing program -* Michael: challenge is that companies want their people to be counted as contributors. - * Discussion: this results in gamification and people not being able to participate - * There’s some organization learning - * We need to be aware of the conflicts -* Rob brought up that there are people entering the community who are not doing things that capture work that’s passive or just using - * Bob described a similar issue w/ Scale where the value is creating data and running tests -* Contributor ladder needs to include people who are using / operating without making code or docs contributions. We want to capture their experience and welcome -* Jess - could even use twitter activity and collect survey results -* Rob - it can be a very good thing to have a large passive audience - * Sarah - as long as there is enough people doing contribution - * Rob suggested that we may want user/operator SIGs that act as onboarding and then direct people to more specific SIGs - -## Conclusions -Key Takeaways / Analysis of Situation - -* SIGs have a lot of passive participants. - **This may be OK** -* We discussed ways to get passive users more engaged including - * introductions at start of meetings - * mentor pairings for new - * asking them about area of interest - * Pairing people for out-of-meeting 1x1 based on time zones - * Keep SIG meeting as status and drive out-of-meeting action -* There is a problem when companies reward people only on contributions of specific types or projects - -## Recommendations & Decisions Moving Forward (High-Level) - -* Create a User SIG for onboarding new users and directing them into other SIGs. This would effectively be an ongoing 101 -* Restart Cluster Ops SIG storytelling for operators and write them down -* SIGs to use off-weeks for office hours - -## Specific Action Items (& Owners) - -None Taken 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 deleted file mode 100644 index fa52f1dc..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md +++ /dev/null @@ -1,146 +0,0 @@ -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)**: sarahnovotny@ -- **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) diff --git a/community/2017-events/05-leadership-summit/session-notes/readme.md b/community/2017-events/05-leadership-summit/session-notes/readme.md deleted file mode 100644 index c7d61f0e..00000000 --- a/community/2017-events/05-leadership-summit/session-notes/readme.md +++ /dev/null @@ -1,6 +0,0 @@ -**Per the [Template & Instruction Document](https://docs.google.com/document/d/1ncrfiVEy_WELqZaNdYOX0_9uuKzuTikgVC-mz2Izsc4/edit?usp=sharing), -upload your session notes here with the name format**: - -*HHMM-HHMM_SESSIONTITLE.md* - -where HHMM is the time in 24-hour format. diff --git a/community/2017-events/12-contributor-summit/ContribSummitInformation.md b/community/2017-events/12-contributor-summit/ContribSummitInformation.md deleted file mode 100644 index 7a6df6a3..00000000 --- a/community/2017-events/12-contributor-summit/ContribSummitInformation.md +++ /dev/null @@ -1,70 +0,0 @@ -# 2017 Kubernetes Contributor Summit Information -fka DevSummit - -## What: -The Contributor Summit provides an avenue for Kubernetes contributors to connect face to face and mindshare about future community development and community governance endeavors. - -In some sense, the summit is a real-life extension of the community meetings and SIG meetings. - -## When: -December 5th, 2017 (before KubeCon) -All day event with happy hour reception to close - -**Agenda:** -Times in CST -- 08:00 am - Registration and light breakfast -- 09:00 am - Welcome and start of content -- 12:00 pm - Lunch provided -- 01:00 pm - Sessions resume -- 05:00 pm - Happy Hour onsite - -View the complete session schedule [here](/community/2017-events/12-contributor-summit/schedule.png). -Session schedule will be available onsite in print as well as on TVs. - -## Where: -Austin Convention Center -500 E Cesar Chavez St, -Austin, TX 78701 -(same location as KubeCon) - -**Registration:** -You'll pick up your summit badge at the same registration tables as KubeCon.* -Level 1, near Hall 1 - -**Breakfast:** -Level 3, Outside of Meeting Room 5 - -**Sessions:** -Level 3, Meeting Room 5 - Welcome @ 9am -Level 3, Meeting Room 4, Meeting Room 6a, Meeting Room 6b - Breakout session rooms - -*_Note-Your summit registration is NOT your KubeCon registration. Tickets are almost sold out for KubeCon, please purchase those separately from the [event page](http://events.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america/attend/register)._ - -## Invitations: -Selected attendees are Kubernetes upstream contributors including SIG members and lottery winners from a [members of standing](/community-membership.md) pool. -We realize that this is not the best approach now that our community is growing in exponential ways. In 2018, we will be unfolding a new strategy for bringing our contributors together so all voices can be heard. - -Invites went out on October 19th. There are ten spots left. Please reach out to parispittman@google.com to claim one. - -## Format: -"loosely-structured unconference" -Rather than speakers and presentations, we will have moderators/facilitators and discussion topics, alongside all-day completely unstructured hacking. - -The discussion sessions will be in an open fishbowl format — rings of chairs, with inner rings driving the discussion — where anyone can contribute. The various sessions will be proposed and voted on by the community in the weeks leading up to the event. This allows the community to motivate the events of the day without dedicating precious day-of time to choosing the sessions and making a schedule. - -There will be 2 rooms dedicated to these sessions running in parallel all day. Each session should last between 45 minutes and an hour. There will be a smaller room available for unstructured discussion all day. - -## Call for Topics: -Call for topics and voting is now closed. You can view the complete list of proposed topics and abstracts [here](https://docs.google.com/spreadsheets/d/1miMinwk3Cp_4KV0xj36gIT3XdN4JtDcnAhkLZxG-qCQ/edit?usp=sharing). - -## Desired Outcomes: -* Generate notes from the sessions to feed the project's documentation and knowledge base, and also to keep non-attendees plugged in -* Make (and document) recommendations and decisions for the near-term and mid-term future of the project -* Come up with upcoming action items, as well as leaders for those action items, for the various topics that we discuss - - -## Misc: - -A photographer and videographer will be onsite collecting b-roll and other shots for KubeCon. If you would rather not be involved, please reach out to an organizer on the day of so we may accomodate you. - -Further details to be updated on this doc. Please check back for a complete guide. diff --git a/community/2017-events/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG b/community/2017-events/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG deleted file mode 100644 index c866d23c..00000000 Binary files a/community/2017-events/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG and /dev/null differ diff --git a/community/2017-events/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG b/community/2017-events/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG deleted file mode 100644 index 8c334121..00000000 Binary files a/community/2017-events/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG and /dev/null differ diff --git a/community/2017-events/12-contributor-summit/breaking-up-the-monolith.md b/community/2017-events/12-contributor-summit/breaking-up-the-monolith.md deleted file mode 100644 index 265dcd60..00000000 --- a/community/2017-events/12-contributor-summit/breaking-up-the-monolith.md +++ /dev/null @@ -1,76 +0,0 @@ -# Breaking Up The Monolith - -Note Takers: Josh Berkus(@jberkus), Aaron Crickenberger (@spiffxp) - -Here's what we're covering: build process, issue tracking, logistics. - -## Question: are we commited emotionally 100% to splitting the monolith - -Opinion: commited, but need to define what that means (past provides the impetus) - -We've been trying [the monolith] for so long and it's too expensive. - -- erictune: as the project matures the core can't keep growing at the same rate -- mattfarina: reason to break it up - developer experience,difficulty to contribute pushes people away from contributing (hard to step into issue queue, etc) -- clayton: I'm scared by this because kubectl is never going to be simpler, it may be easier to just write a new one -- erictune: ecosystem yes, more contributors... narrowly defined core no -- bburns: we don't do a good job of measuring the cost of this, we love breaking things up because it's "cleaner" but we're not estimating the cost in terms of the human effort and complexity -- lavalamp: respectfully disagree, we _have_ estimated the cost, knew it was going to be painfu but we haven't had a choice -- timstclair: nobody has ever answered the question to be of how we're going to deliver a set of binaries as part of a release, there isn't a cohesive plan for doing this -- timstclair: how are you actually going to get test infra to test all the things -- bburns: how do you actually find the commit that causes a failure in e2e -- lavalamp: have you see the doc I have posted everywhere this comes up? (TODO: link) main repo becomes integration point, binary artifacts produced by other repos -- clayton: kubectl is a very "big" thing, if we said the problem is that kubectl itself is too big, it might be better to focus on something new and novel, it might be better to build a community around that -- dims/matt: can we have a list of four or five items we want to move out in priority - - Kubectl - - Client-Go? (but that's already published separately) (this is way too involved for this session) - - Try to tackle "how do we deal with client-go" elsewhere - - kubeadm is in main repo to catch release train, wants to move out, but it's fairly hard. We tried to move it out, but couldn't and follow the release train. -- clayton: government approach: why build one thing when we can build two for twice the cost? an (extracted) client-go that's all high-perf, a completely rewritten client-go that's human focused and more reusable - -## Question: Do we understand the problem we're trying to solve with the repo split - -Assumption: contributor velocity is correlated with velocity, new contributor experince -Assumption: "big tangled ball of pasta" is hard to contribute to - -- thockin: our codebase is not organized well (need to make it easier to actually *find* what you want to contribute to) one of the things we could do is "move code around" until it looks effectively like there are multiple repos in our repo? eg if we centralized all of the kubelet logic in one directory except for one util directory, maybe that would be an improvement -- jberkus: people who work on other large projects say that modularity is the way to go. Not necessarily seperate repos, but a modular architecture. -- thockin: what we've done with github bots alleviates a lot of the pain we've had with github -- dims: two problems - - vendoring in all kinds of sdk's that we don't care about, they get dragged in (e.g. AWS SDK) and if you're only working on eg: openstack related stuff, it's hard to get signoff on getting other stuff in if it's in your own repo it's easier to do that than in the main repo - - (guess we missed #2) -- erictune: we've already promised people cloud providers you can write in different ways, extensibility of apis, operators, if we deliver on all this we will have enough modularity to improve user/developer experience -- mattfarina: I think you're right about that -- First thing: we're breaking up cloud providers, it helps let the long tail of cloud providers go out - - what about storage providers, if we break them up there's a clear interface for storage providers -- second thing: here are api/components that are required, required but swappable, optional... how can you do that swapping around of stuff in the monorepo -- robertbailey: when I proposed this session I thought we had all agreed that breaking the repo was the way to go, but maybe we don't have that conensus could we try and figure out who is the decision maker / set of decision makers there and try to come to consensus -- dchen1107: I heard a lot of benefits of the split. So there's a huge cost for release management, as the release manager, I don't know what's in the other repositiory. Clear APIs and interfaces could be built without needing separate repositories. Gave example of Docker and CRI, which got API without moving repos. -- Example of Cloud Foundry, build process which took two weeks. How do we ensure that we're delivering security updates quickly? -- thockin: We can put many things in APIs and cloud providers are a good example of that. Splitting stuff out into multiple repos comes down to the question of: are we a piece of software or a distribution? You'll have to come to my talk to see the rest. -- spiffxp: Increasing our dependancy on integration tools will add overhead and process we don't have now. But I understand that most OSS people expect multiple repos and it's easier for them. Github notifications are awful, having multiple repos would make this better. The bots have improved the automation situation, but not really triaging notifications. How many issues do we have that are based on Github. Maybe we should improve the routing of GH notificaitons instead? -- solly: if we split, we really need to make it easier for tiny repos to plug into our automation and other tools. I shouldn't have to figure out who to ask about getting plugged in, we should have a doc. We need to make sure it's not possible for repos to fall through the cracks like Heapster, which I work on. -- bgrant: We're already in the land of 90 repos. We don't need to debate splitting, we're alread split. We have incubator, and kubernates-client. I think client has helped a lot, we have 7 languages and that'll grow. -- bgrant: the velocity of things in the monorepo are static -- thockin: if issues in the main repo are more than 6 weeks old, nobody looks at it. There's like 400-500 abandoned "network" issues. -- bgrant: we tested gitlab and gerrit, and importing kubernetes failed. We didn't find them that much better. -- spiffxp: we have hundreds of directories with no owners files, which is one of the reasons for excessive notifications. -- bgrant: kubernetes, as a API-driven system, you have to touch the api to do almost anything. we've added mechanisms like CRD to extend the API. We need SDKs to build kube-style APIs. -- dims: I want to focus on the cost we're paying right now. First we had the google KMS provider. Then we had to kick out the KMS provider, and there was a PR to add the gRPC interface, but it didn't go into 1.9. -- thockin: the cloud provider stuff is an obvious breeding ground for new functionality, how and if we should add a whole seperate grpc plugin interface is a seperate question -- jdumars: the vault provider thing was one of the ebtter things that happened, it pushed us at MS to thing about genercizing the solution, it pushed us to think about what's better for the community vs. what's better for the provider -- jdumars: flipside is we need to have a process where people can up with a well accepted / adopted solution, the vault provider thing was one way of doing that -- lavalamp: I tend to think that most extension points are special snowflakes and you can't have a generic process for adding a new extension point -- thockin: wandering back to kubernetes/kubrnetes "main point", looking at staging as "already broken out", are there other ones that we want to break out? -- dims: kubeadm could move out if needed, could move it to staging for sure -- thockin: so what about the rest? eg: kubelet, kube-proxy... do we think that people will concretely get benefits from that? or will that cause more pain -- thockin: we recognize this will slow down things -- lavalamp: there are utility functions that people commonly use and there's no good common place -- lavalamp: for kubectl at least it's sphaghetti code that pulls in lots of packages and makes it difficult to do technically -- thockin: do we think that life would be better at the end of that tunnel, would things be better if kubectl was a different repository, etc. -- timallclair: I'm worried about dependancy management, godeps is already a nightmare and with multiple repos it would be worse. -- luxas: in the kubeadm attack plan, we need to get a release for multiple repos. We need the kubeadm repo to be authoritative, and be able to include it in a build. -- pwittrock: how has "staging" improved development? can we see any of the perceived or hoped-for benefits by looking at staging repos as example use cases? -- lavalamp: getting to the "staging" state and then stopping is because api-machinery was unblocked once we got there -- thockin: the reason I consider "staging" solved, is you have to untangle a lot of the stuff already -- erictune: I would make a plea that we finish some of our started-but-not-finished breakaparts \ No newline at end of file diff --git a/community/2017-events/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md b/community/2017-events/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md deleted file mode 100644 index 66aadf88..00000000 --- a/community/2017-events/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md +++ /dev/null @@ -1,60 +0,0 @@ -**Contributor Summit - KubeCon 2017** - -**Cloud Native Design/Refactoring across Kubernetes** - -*Lead: Joe Beda(**[@jbeda](https://twitter.com/jbeda)*)* - -*Co-lead: Amit Kumar Jaiswal(**[@AMIT_GKP](https://twitter.com/AMIT_GKP)*)* - -**Abstract** - -Explore how to cleanly support cloud-native behaviors, such as standardized Kubernetes logs, injectable configuration and common queryable APIs in Kubernetes components. While this discussion isn't only about containers, orchestrating OpenStack deployment/management within Kubernetes via OpenStack-Helm or Kolla-Kubernetes paves the way for better upgrade capabilities. They will also improve the ability to run individual Kubernetes services independently or in combination with other adjacent technologies. - -**Agenda** - -1. Cloud Native Ecosystems - -2. Kubernetes Abstractions & Primitives - -3. Kubernetes Design Patterns - -4. Refactoring across Kubernetes - -5. Benefits of using Kubernetes - -**Issues** - -** **- We’re looking for someone to help us out on issues related to refactoring across Kubernetes like [Issues#51405](https://github.com/kubernetes/kubernetes/issues/51405), [#46735](https://github.com/kubernetes/kubernetes/issues/46735), [#54090](https://github.com/kubernetes/kubernetes/issues/54090), [#55151](https://github.com/kubernetes/kubernetes/issues/55151) - - - Consolidating volume util files like *pkg/volume/util.go, pkg/volume/util/util.go, pkg/volume/util/volumehelper/volumehelper.go *[need better documentation of each file is to emcompass] - - - Enhancing e2e tests to track cloud provider’s API Quotas - - - Like changing fluentd to use CRI log Path and eventually deprecates the old container path - - - Issues with deploying/adopting Kubernetes for specific applications use-cases - -**Questions** - - - Security and granularity across Kubernetes - - - Kube API issues like it should not depend on *--cloud-provider* and *--cloud-config* - - - Helping us out with API documentation and Configuring Best Practices? - - - What are the new tools to deal with testing frameworks for NFV/SDN across Kubernetes? - - - Kubelet Flag subfields precedence v/s files/ConfigMaps to Kubelet Config - - - How to dynamically provision an AWS EBS volume from a snapshot? - - - Work around Object definition in OpenAPI schema like definition of the *PersistentVolumeSpec, PersistenceVolumeClaimSpec* - - - Work around support for FUSE client for K8s cephfs. - - - -**Audience Feedback** - - - - diff --git a/community/2017-events/12-contributor-summit/cloud-provider.md b/community/2017-events/12-contributor-summit/cloud-provider.md deleted file mode 100644 index a18a0fb7..00000000 --- a/community/2017-events/12-contributor-summit/cloud-provider.md +++ /dev/null @@ -1,86 +0,0 @@ -# CloudProvider Update -*Lead: Walter Fender / cheftako* -*Notetaker: Jago Macleod / jagosan* -4pm - -Goals: - -Make it easy for any new cloud provider to be able to add support for new cloud provider without having to submit code to k/k repo. [good shape!] -For currently in-tree cloud providers to be able to build and release without having to ‘wait’ for upstream kubernetes. (e.g. security patches and features) -Also suboptimal that for technical reasons, other cloudprovider’s ‘init’s are being run in the hosting cloud provider’s environments. - -[TODO: name?]: From a user’s perspective, you might like a more modular cloudprovider. You might want ELB but not the storage from that cloudprovider. - -cheftako: where are we: - -There is a PR out that is a WIP that proves that in GCE it is possible to bring up a cluster - -Kube-controller-manager is disabled. cloud-controller-manager is working there - -Kube-mark tests are a challenge. No support for conditional behavior in test-infra. Now we need an n1-standard2 master. - -Other outstanding issues: - -Who has seen the following in the tests: - -If !GCE -> skip. - -Many raise hands. This is recognized as a gap that needs to be addressed. - -Also need volunteers for each of the cloud providers. Lot of work to be done. - -Thockin would like to minimize the amount of code that lives outside of k/k repo. If we were to take all of lifecycle and move it out of k/k, there is a lot of functionality that could diverge, or could be missing for a user in certain cloud providers. - -Take a page out of API Server book and make a generic controller manager and use for kube-controller-manager and cloud-controller-manager. - -Comment: spent a couple of days looking through the GCE work and found ~4 bugs. So there are a bunch of other - -Broke node controller out into 4 segments. - -Overview on where we are in the overall project: external cloud provicer - -We have a long way to go before all the in-tree cloud providers are moved out. - -One of the interesting questions is that eventually there are no in-tree cloud providers; there is now a distributed CI issue where all cloud providers have a mechanism through which to set up their own continuous testing and post results back to testgrid, to expose when changes to one area of the code inadvertently break one or many or all cloud providers. - -MS has a proof of concept basically done. Some questions: legally, what does this mean? E2E tests - how to make blocking. OpenStack -- in e2e tests, there is no tag to ensure nothing was broken in e2e. - -Jaice: to complicate matters, there may be primitives that make it necessary to make the testing much broader. There is a greater chance that the flakes occur in this world. - -thockin - on indemnity, we can make a dedicated repo that is still CNCF owned but controlled by cloud provider - -Exercise the top level interface - -Multiple levels of test here. In the final state, there is no ‘cloudprovider’ interface. You can test that binary / or binaries to test specific cloud implementations; then there is another level which is the e2e tests of basically everything that is the kubernetes functionality. - -When it comes to timing: the original plan was to depend on Flex Volumes. Subsequent discussions have tended toward depending instead on CSI as the volume solution. This means the timing is no earlier than Q3. - -Victory looks like this: - -Major cloud providers shipping and running cloud-controller-manager. Volumes can remain behind until CSI is production ready. - -Also, when we can eventually delete all the in-tree cloud provider code, thockin will buy the cake and the keg. - -Today, when you deal with CCM, and it says ‘what is my cloud provider’ it turns off cloud plugin, and volumes doesn’t work. There is, therefore, a new flag. Set cloudprovider=external and some other flag, can’t remember off top of head. Intention is that this will be a temporary second flag and will be removed as soon as possible. - -A lot of really good work has been done. Need to do a better job of organizing code in KCM & CCM. - -Open Question: will we ship cloud provider specific CCM’s as part of the kubernetes release? - -Or, what cloud providers are included or easily available with the binaries distributed in the Kubernetes release? - -Can we define better criteria than ‘you showed up before date xxxxxx’. - -Perhaps there is something that will work for a ‘vanilla’ system or locally, and some way to discover and install CCMs for available cloud providers. Likely the vendor / distributor will be packaging up some other process by which kubernetes is installed and configured. - -Thockin - think about what you do when you compile the linux kernel. Choose options during initialization and customize to hearts content. At the end, you get an artifact. Kbuild. Did a hack 18 months ago and proved it’s possible. - -thockin - do we have concrete list? Not a great list. We are going through the KEP process. AI: call to action. - -We are committed; we are making progress; we meet wednesdays at 10am Pacific Time. - -Fejta: think about a local provider. Move as much as possible onto something that is like minikube, e.g. Great enthusiasm for this concept. - -AI: fejta to share information on how to submit test results to testgrid and how to leverage the tooling for external cloud providers. - -Summary - yes! diff --git a/community/2017-events/12-contributor-summit/container-identity.md b/community/2017-events/12-contributor-summit/container-identity.md deleted file mode 100644 index 06a53a79..00000000 --- a/community/2017-events/12-contributor-summit/container-identity.md +++ /dev/null @@ -1,168 +0,0 @@ -Container identity - -Lead: Greg Castle - -How are people using k8s service accounts - -* Default service accounts? - -* User: - - * (Zalando) - - * 55 clusters - - * Only allow pre-set service accounts postgres "operator service accounts" - - * Don’t enable RBAC - - * Namespaces: usually use the default namespace, more sophisticated clients can use namespaces - - * Cluster per product - - * CRD that defines request for an OAuth2 token - - * Q: Would you want to tie it to a Kubernetes service account. E.g. annotation on a service account to get an OAuth2 token - - * (IBM) - - * Strict way of "cutting up cluster" - - * No team has access to the Kubernetes API - - * Humans do, pods don’t - - * Admins create service accounts and role bindings - - * Issues with pod authors in the namespace can run any service account. - - * Is there a missing binding to control the right to use a service account? - - * Namespace boundary - - * Application - - * (VMware) - - * 1 cluster - - * Projects are per-namespace (200 namespaces) - - * Wrote an admission controller between which pod is using which service account. Denies certain kind of changes. - - * Ownership model "I created this object, only I can change it" - - * Namespace but wanted sub-namespace primitives - - * Service accounts have labels, need to match the pod. - - * Q: Why not just different namespaces? - - * Don’t want to give users the ability to create namespaces - - * (Jetstat) - - * Dev, staging, and prod cluster - - * Namespace per team - - * Their developers don’t have permissions to create workloads - - * CI system is the thing that creates workloads, that controls stuff - - * (CoreOS) - - * Customers create namespaces that are controlled by CI/CD - - * Users have read-access to cluster - - * Central catalog controls the service account - - * Authoritative on RBAC - - * Catalog is currently controlled by CoreOS, can be used by users later - - * Namespaces - - * Catalog is enabled on a namespace - - * Also use service accounts to authenticate CI/CD systems - -* Container identity - - * Authenticate workloads against each other - - * Does this fit into the current way you use service accounts? - -* What about envoy istio? - - * Complementary efforts - - * Services can do service to service auth - - * Maybe not solving "I want to talk to s3, I want to talk to GitHub" - - * Give them a better way to provision x509 certs - - * Istio will be dependent on container identity - - * Istio and SPIFFE? - - * Istio is using SPIFFE conformant x509, not the workloads API - -* Q: how does Zalando RBAC CRDs? - - * Trust two engineers that have the permissions to create the CRDs - - * Emergency procedure with time limited API - -* Q: multiple clusters working together? - - * IBM: going to face it - - * CoreOS: thinking about users authenticating across multiple clusters through sharing public keys. - -* Liggitt: namespaces are the boundaries of trust - - * Originally thought about using pod templates so admins could create specific templates that pods MUST use. - - * Reference pod template in RC or deployment instead of inlining them - - * Never bubbled up to be the most important thing yet - -* Liggitt: Kubernetes API isn’t really designed for things that hold credentials - - * Moving the mounting and creation of the service account to the kubelet through flex volumes - - * Helps you leverage the node level integrations - -* Q: what about the secrets proposal? - - * KMS is being added - - * No change for encrypting the secret as you read it - -* Slides - - * Authorization should apply to the identity, rather than the namespace - - * Is multiple SA per namespace an anti-pattern? - - * Useful for bounding process within pods to certain permissions - - * Problem when a SA from cluster scoped manifests - -* Q: kerberos and vault bindings implemented as flex volumes - - * Is it important to have standard identity mechanisms? (Yes) - - * Can we add it to conformance? - - * Avoid lock-in for IAM - - * Cluster identity also becomes an issue too - - * Pod/UID/Namespace/Cluster - -* Potentially use OpenID Connect format so others can use that spec - diff --git a/community/2017-events/12-contributor-summit/current-state-of-client-libraries.md b/community/2017-events/12-contributor-summit/current-state-of-client-libraries.md deleted file mode 100644 index c7ac0bad..00000000 --- a/community/2017-events/12-contributor-summit/current-state-of-client-libraries.md +++ /dev/null @@ -1,38 +0,0 @@ -Story so far is described at https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/csi-client-structure-proposal.md -- linked from https://github.com/kubernetes-client/community/blob/master/design-docs/clients-library-structure.md - -Would like libs to be more "fluent" - should join up with the native language features e.g. JavaDoc, per-platform - -OpenAPI (Swagger) has limitations which force ugly workarounds. - - e.g. doesn't cover returning different types in response to a call e.g. a result or an error. - - OpenAPI 3 fixes a number of these limitations - -Key difficulty is which verbs apply to which objects - Go doesn't natively have this concept. - -OpenAPI doc is produced by running an api-server, which knows how to dispatch verbs to objects, and having it generate the OpenAPI - -Should we deprecate SPDY in favour of websockets? (probably yes) - -What do people want in a client library? - - Go lib smaller than 40MB - - Go lib with dynamic types (this exists?) - - Rust - - C++ - -Are there client libs for things like service catalog? Where do those live? - -How can clients talk protobufs to api-server? Set the content-type. - -K8s protobuf def uses an 'envelope' type covering things like storage version - -Protobuf not self-describing so not great for api-server CRUD operations - -A few bits of extra information in the protobuf definition would be great - e.g. pluralisation - -Client SIG is relatively under-represented and relatively easy to join in - please come along! - -kubeconfig semantics are not standardised - when reimplemented in different languages this can give unexpected results. Example: URL with no scheme supported by Go but not Java - -How should clients deal with rolling authorisation certificates? - -There are type wrinkles, like "intorstring" and "quantity" \ No newline at end of file diff --git a/community/2017-events/12-contributor-summit/dashboard-ux-breakout.md b/community/2017-events/12-contributor-summit/dashboard-ux-breakout.md deleted file mode 100644 index 3dad6fe2..00000000 --- a/community/2017-events/12-contributor-summit/dashboard-ux-breakout.md +++ /dev/null @@ -1,94 +0,0 @@ -Kubernetes Dashboard UX breakout session 12.5.17, led by Rahul Dhide ([rahuldhide](https://github.com/rahuldhide)) and Dan Romlein - -* **Resources:** - - * Dashboard [User Types #975](https://github.com/kubernetes/dashboard/issues/975) - - * Dashboard [User Types and Use Cases](https://docs.google.com/document/d/1urAlgRP7AbcdsOMQ_piQQ6O1XTDIum_LmOUe8xsC4pE/edit) - - * [SIG UI weekly](/sig-ui) - -* **Notes** - - * 2018 Dashboard strategy. - - * [Deck](https://docs.google.com/presentation/d/1q1G1vWCrenI3GVsyF4d-2rpyVrdJgFW7fIbvcAAd9Lg/edit?ts=5a26f250) - - * [Github issue](https://github.com/kubernetes/dashboard/issues/2556) - - * **Kubectl access via Dashboard**. - - * Dhaval: Provide context to issues. - - * **Third-party Widgets**. - - * **Custom Views**. - - * Dhaval: Custom views will be very useful to share the event details, contextual information, and logs with specific time ranges. It will help our development teams to quickly analyze the issues. - - * Henning: UI should allow users to pick the important properties in different views/widgets. - - * **Integrations and CRDs**. - - * **Onboarding experience**. - - * Jared: Currently there is no crosslinking between docs and the UI. We can explore the concept and impact further. - - * **Design system.** - - * e.g. Standard for how a pod’s status is displayed. - - * Different use cases/personas - - * application developer - - * application operator - - * (multi-)cluster operator - - * **Feedback from Dhaval and Hennings:** - - * "We don’t use Dashboard, because of lack of authorization control." - - * "Dashboard today caters to the dev perspective, which is OK." - - * But for ops, currently missing dependency stacks (e.g. OS version) "I want to know different node versions." - - * "Our developers use Dashboard for the logs" - - * "When we perform troubleshooting & debugging we expect 30 min before and after incident. - - * Want to be able to link users to docs for more info; "What’s a pod? What’s a deployment?" - - * *Contextual docs* displayed in UI. - - * Idea: Dashboard could scrape docs. - - * Kubernetes docs working on expanding [glossary](https://kubernetes.io/docs/reference/glossary/?fundamental=true) - - * Dashboard is backwards compatible. - - * Demo of [Kubernetes Operational View](https://github.com/hjacobs/kube-ops-view) - - * Use Case: - - * Onboarding: explain resource limits vs. resource requests. - - * Quickly looking at a cluster and knowing what’s going on. - - * "I really like this UI" - - * Wanted to gamify K8s with this UI. - - * "My cluster has 118 nodes, so the ability to filter would be important." (general scale issues) - - * "Problem we’re running into is that the number of nodes will crash the browser, so we need some way to select cluster first" - - * Defining a view is hard, Dashboard shouldn’t attempt to do that. - - * Use case for custom Dashboard re-skinning. - - * "My exec looks at the look and feel." - -* Kubernetes Dashboard 2017 User Survey: [https://docs.google.com/forms/d/e/1FAIpQLScnxeub_xh7Lp4iZO1RKdTgIYK_cTwqFKv1WD-Cue4tZHcbhw/viewform?usp=sf_link](https://docs.google.com/forms/d/e/1FAIpQLScnxeub_xh7Lp4iZO1RKdTgIYK_cTwqFKv1WD-Cue4tZHcbhw/viewform?usp=sf_link) - diff --git a/community/2017-events/12-contributor-summit/enabling-kubernetes-ecosystem.md b/community/2017-events/12-contributor-summit/enabling-kubernetes-ecosystem.md deleted file mode 100644 index 50be4b66..00000000 --- a/community/2017-events/12-contributor-summit/enabling-kubernetes-ecosystem.md +++ /dev/null @@ -1,134 +0,0 @@ -# Kubernetes Ecosystem - -Notes by @directxman12 - -* How do we e.g. have an object validator - - * Went looking, found 2, second b/c first didn’t work well enough - -* How do we enable people to build tools that consume and assist with working with Kubernetes - - * Kube-fuse, validatators, etc - - * How do we make those discoverable - - * Difficult to find via GitHub search - - * Difficult to find via search engines (find blog posts, etc, and not the tools) - -* Proposal: structured content (tags, categories, search) for registering and discoverability - -* Are there examples of ecosystems that we can follow - - * Package managers (PyPI, crates.io, NPM) - - * Doesn’t quite fit one-to-one b/c some stuff is best practices, etc - - * Docs, stuff like CNI plugins, etc doesn’t actually work well the same view as things that run on Kubernetes - - * At the basic point, just need to find what’s there - - * Traditional package managers focus on consuming the packages - - * If you don’t have packaging, it’s hard to approach (see also: Freshmeat problems) - - * Hadoop: classes that map the Hadoop ecosystem, infographs - - * Wordpress, Drupal are good examples - - * Ansible Galaxy - - * Chrome Extensions/Eclipse plugins - - * Look for things tagged, if comments say "broken" and last update is old, don’t use it - - * Packagist (PHP package repository) - - * Integrates with GitHub, pulls in details about updates, README, extensibility, etc from GitHub - - * Just helps with discoverability - - * Steam - - * Has curated lists by users - -* Opinion: End users need focused, distributable bundles - - * Most people don’t need to do all of everything - - * Different systems for apps vs critical infrastructure - - * Critical infrastructure doesn’t change much - - * Still need to discover when initially building out your system - -* Issue: people get overwhelmed with choice - - * We don’t want to endorse things -- users should choose - - * We could let people rank/vote/etc - - * For example, what’s wrong with an "awesome list" - - * Need to look at human-consumable media, not necessarily machine-consumable - -* Question: do we currate - - * Do we require "discoverable" things to be maintained/use a CLA/etc? - - * Opinion: no, we can’t possibly curate everything ourselves - -* It’s problematic if you can discover new things, but they’re not supported by your Kubernetes distros - - * Not as much a problem for apps stuff, but harder for infrastructure - -* Doesn’t GitHub have labels, stars, etc - - * Yes! - - * We could just say "always label your GitHub repo with a XYZ label if you’re a CRI plugin" - - * Comes a bit back to curration to discover benefits of each - - * Enterprises, gitlab make this infeasible - -* Core infrastructure is a bit of an edge case, perhaps focus on addons like logging, monitoring, etc - - * Still comes back to: "if distro doesn’t support well, will it still work" - -* Issue: there’s things people don’t know they can choose - - * E.g. external DNS providers - -* Have a partially curated list of topics, but not curate actual content - - * Maybe leave that up to distros (have different collections of options -- e.g. open-source only, etc) - - * Have "awesome-kubernetes" - -* Let SIGs curate their lists? - - * Having all the SIG be different is difficult and confusing - - * SIG leads don’t necessarily want to be the gatekeepers - - * We don’t necessarily want to tempt SIG leads with being the gatekeepers - -* If we have something "official", people will assume that stuff is tested, even if it’s not - -* Can we just have distributions that have way more options (a la Linux distros) - - * There are currently 34 conformant distros - -* If we have ecosystem.k8s.io it’s really easy for people to find how to find things, otherwise could be hard - - * E.g. people don’t necessarily know awesome lists are a thing to search for - -* Someone should do a prototype, and then we can have the conversation - -* Question: where should this convo continue - - * SIG Apps? - - * Breakout group from SIG Apps? - diff --git a/community/2017-events/12-contributor-summit/extending-kubernetes.md b/community/2017-events/12-contributor-summit/extending-kubernetes.md deleted file mode 100644 index ee21aea2..00000000 --- a/community/2017-events/12-contributor-summit/extending-kubernetes.md +++ /dev/null @@ -1,215 +0,0 @@ -# Extending Kubernetes -Note Taker: Clayton Coleman ([smarterclayton](https://github.com/smarterclayton)) - -* Questions - - * Do we have enough extension mechanisms? - - * See below - - * Implementing network injection that isn’t a CNI injection of some form is hard - - * e.g. adding in arbitrary network devices, for example - - * Are Flex Volumes enough? - - * Maybe? - - * Are we doing ok on kubectl extensions? - - * Yes, we’re heading in the right direction with plugins - - * Kubectl itself should be developed using its own mechanisms - - * Extension points: - - * OpenAPI metadata (operate on object w/o knowing about it) - - * Subresources (generic API-level interfaces for certain facets) - - * Plugins (git-style) - - * Can we do custom validation in kubectl? - - * Do it via admission webhooks (beta in 1.9) - - * Can run validation asynchronously, and report it (put a condition in) - - * Client-side validation is iffy - - * Should we have phased hooks? - - * Should more complex application lifecycle layer on top? - - * Are we consistent enough across our hooks to enable users to build something sane? - - * Can we do referential integrity - - * Technically, with a webhook - - * Generally not the best idea (causes issues with components that don’t expect it) - - * Can maybe do with initializers on a namespace - - * Generally go for eventual consistency (e.g. wait for the secret to exist before starting the pod) - - * Reasons - - * Surface errors to users synchronously - - * Do it on the client-side - - * Avoid dealing with the full matrix of failure modes - - * How do we not re-invent a service mesh with auth webhooks? - - * It’s an open question - - * Can we do conversions on CRDs - - * Maybe with a webhook (ongoing discussion) - - * Why aren’t Custom API servers easy enough - - * Need OpenShift certificate signing mechanisms in Kube, or similar (also exists similarly in Istio) - - * Storage - - * Re-use existing etcd - - * Use your own etcd - - * Planned backing custom API servers with CRD storage - - * Why aren’t they more uniform - - * Because they came at different times - - * It’s hard to fix them now (need more versioning) - - * Different layers have different needs - - * Declarative is API - - * Below Kubelet is gRPC - - * gRPC for KMS, CSI - - * CNI is shell execution (mainly for legacy reasons) - - * Can we make custom controllers easiers? - - * OperatorKit - - * Need better docs (being worked on) - - * Untyped vs generated typed informers and listers - - * No Go generics exists - - * Can use interfaces - - * Can use conversions (may be harder than it needs to be) - - * Can wrap in a generic type (e.g. RBAC types) - - * Generating clients for CRDs (look for stts’s blog post on generators and informers) - -* Existing extension mechanisms - - * API Extensions - - * External APIs (Aggregated APIs) - - * Custom Resources - - * Admission/Early-Phase ext points - - * Initializers - - * Can’t do in updates - - * Webhooks - - * Need to make them easier to implement (and a good example) - - * Pod Presets (ish) - - * Webhooks have to be fast, initializers are more async (normal controller style, with restraints) - - * Finalizers (late-phase ext points) - - * Flex Volumes - - * Being used to prototype container identity work, too - - * CSI (soon™) - - * (grpc) CRI - - * (binaries) CNI - - * (webhook) Auth plugins - - * Authz - - * Authn - - * Groups from authn hook ??? - - * (API server) Custom metrics API servers - - * (grpc) Device plugins - - * (grpc) KMS (Key Management) - - * (git style) kubectl plugins - - * (API usage) Any controller - - * External Cloud Provider - - * Pod lifecycle isn’t extensible - - * Object phase - - * Init containers (do exist) - - * defer containers - - * Lee’s debug container - - * Logging plugins - - * Was a proposal for logging volumes, didn’t get follow-up - -* New Extension type things - - * Enumerations in the API - - * Conditions (new condition types) - - * Loose coordination between multiple controllers - - * Signal to end users - - * Exists until formalized as a field - - * runc hooks - - * Could be a CRI concern - - * Optional CRI sub-interfaces? - - * Identity injection (custom CA certs in every pod, etc) - - * Simplifying the creation of controllers with controller generation ie. metacontroller: [https://github.com/GoogleCloudPlatform/kube-metacontroller](https://github.com/GoogleCloudPlatform/kube-metacontroller) - - * API server builder: [https://github.com/kubernetes-incubator/apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder) - - * Operator pattern toolkits: - - * Rook Team: [https://github.com/rook/operator-kit](https://github.com/rook/operator-kit) - - * GiantSwarm: [https://github.com/giantswarm/operatorkit](https://github.com/giantswarm/operatorkit) - diff --git a/community/2017-events/12-contributor-summit/feature-roadmap-2018.jpg b/community/2017-events/12-contributor-summit/feature-roadmap-2018.jpg deleted file mode 100644 index 6b69204a..00000000 Binary files a/community/2017-events/12-contributor-summit/feature-roadmap-2018.jpg and /dev/null differ diff --git a/community/2017-events/12-contributor-summit/feature-roadmap-2018.md b/community/2017-events/12-contributor-summit/feature-roadmap-2018.md deleted file mode 100644 index d2ae01ac..00000000 --- a/community/2017-events/12-contributor-summit/feature-roadmap-2018.md +++ /dev/null @@ -1,336 +0,0 @@ -Contributor summit - Kubecon 2017 - -**@AUTHORS - CONNOR DOYLE** - -**@SLIDE AUTHORS ARE THE PRESENTERS** - -**@SKETCHNOTES AUTHOR DAN ROMLEIN** - -# 2018 features and roadmap update - -Presenters: Jaice, Aparna, Ihor, Craig, Caleb - -Slidedeck: https://docs.google.com/presentation/d/10AcxtnYFT9Btg_oTV4yWGNRZy41BKK9OjK3rjwtje0g/edit?usp=sharing - -What is SIG PM: the "periscope" of Kubernetes - -* They look out for what’s next, translate what’s going on in the community to what that means for Kubernetes - -* Responsible for Roadmap and Features Process - -Understanding the release notes is difficult sometimes since the docs aren't always done by the time the release team is compiling the notes. - -## Retrospective on 2017 - -* What did we do since Seattle - -* Feedback on how we can enhance SIG-PM - -* Moving from "product-driven" to "project-driven" where SIGs are defining their roadmaps based on market, end-use input etc. - -Major 2017 Features: - -* (Apps) Workloads API to Stable - -* (Scalability) 5k nodes in a single cluster - -* (Networking) NetworkPolicy - -* (Node) CRI, GPU support - -* (Auth) RBAC stable - -* (Cloud providers) Out of core - -* (Cluster Lifecycle) kubeadm enhancements - road to GA in 2018? - -* (Autoscaler & instrumentation): custom metrics for HPA - -* (Storage) CSI (Container Storage Interface) - -How did we do on the contributor roadmap? - -* [See 2017 roadmap slides](https://docs.google.com/presentation/d/1GkDV6suQ3IhDUIMLtOown5DidD5uZuec4w6H8ve7XVo/edit) - -Audience Feedback: - -* Liked that it felt like there was a common vision or theme last year. - -* Liked that there was a PM rep saying "do docs", "your tests are failing" etc - -* Leadership summit 6 months ago: shot heard called was "stability releases, stability releases". Not sure that 1.8 was really a stability release, not sure 1.9 is either. Will 2018 be the year of stability (on the desktop) - - * (Brian Grant) Come to the feature branch session! - - * Notion of stability needs to be captured as a feature or roadmap item to talk and brag about. Quantify, talk about as roadmap item - - * Idea for 2018: how do you measure and gamify stability? See a number in the red, people will want to fix. Testing, code quality, other metrics - might improve stability organically - - * Context of stability and testing: achievement was conformance program. 30+ conformant distros! - - * Want to see project continue to be useful: within your SIG, invest in conformance, extending suite. Going back to what is and is not k8s - define core, extensions: don't compromise the stability of the core. - - * Please come see Eric Tune and define stability : - - * "cluster crashed" - - * "too many features" - - * "an API I was using stopped working" - - * "community is chaotic, how do I navigate that" - -* There are many new alpha features in each new release. Please prioritize graduating and stabilizing the existing features. (More than 50 APIs already) - -* Looking for volunteers on writing a stability proposal? - -* Jaice has one already! - - * *May* have broken the comment limit on Google Docs - - * Need to define lens: - - * architecture, community etc; look at a proposal under each. - - * Brian is working on arch stability. - - * Contribex is looking at mentorship and ladder. - - * Myriad of ways to approach problem set. How do we mature the processes of the Kubernetes ecosystem? - -* Looking for co-authors? - -## Proposals and KEPs - -(Caleb) - -Please hang out in SIG-Arch, SIG-Contribex, SIG-PM to drive this process forward - -Looking at "is this feature ready to move to the next stability milestone?" (Alpha to Beta, Beta to GA etc) - -* Proposals are now **K**ubernetes **E**nhancement **P**roposals - - * Piece-by-piece over on more multiple releases (living documents) - - * Looked at a lot of other open source projects, e.g. the Rust community (RFC Process) - - * designed in the era of GitHub; decided on a lightweight process that works well with the VCS. - -* Talk about what we want to do without a long spec doc, about what we agreed to ahead of time, but* don't want to diverge 2 years later*. - -* Helps tracking individual features (easier to read release notes) - - * Release note writing take tracking down a lot of docs, GitHUb issues, design docs, Slack and Google Group comments; combine from a bunch of places - - * Hard to tell from the release notes what's important and what's a minor detail. - -* Every SIG should set their own roadmap - the KEP proposal enables that. - -* Template that asks you to think ahead for the lifecycle of the feature; let people know what you're planning to do. - - * It's a medium for comms; not saying "It has to be done this way" but saying why this is important. - - * Inspired by "[Toward Go 2](https://blog.golang.org/toward-go2)" blog post by rsc - -* Has been tested - [draft KEP for Cloud Providers](https://github.com/kubernetes/community/pull/1455), Tim St. Clair has tested. - -* Want to make easier for new contributors to write KEPs. - -* Starting with "what is a unit of work, how do people care" - -Questions: - -* Are KEPS google docs, or pull requests, etc? How do you submit one? - - * Original intend: something that lives in source control. Discoverable like any part of the code. Attempt to combine design proposals and umbrella GitHub issues, link to 10s of other issues. They will live as long as we're a project; doesn't depend on hosting providers. - - * Vision is that writing KEPs, know from them what the roadmap is; can write the blog post based on the value articulated in the KEPs. - - * Right now they are [buried in community repo](/contributors/design-proposals/architecture/0000-kep-template.md) 3 levels deep: a lot of great feedback so far. Joe wouldn't object to making it more discoverable. - - * Kep.k8s.io for rendered versions? - - * Rust community has a sub-repo just for this (rust-lang/rfcs) - - * More than one person has said that KEPs weren't known about - move to somewhere discoverable sooner rather than later. Who can own that action? Matt Farina from Samsung is keen to help but doesn't have resources to lead. - - * *Can only have its own repo if we get rid of features repo!* - - * Don't want anyone to do anything not adding value to work; hope is that KEP is worthwhile and adds value. Caleb will help drive, and create repos as needed. - -## Features - -(Jaice) - -Features repo and process: I will say what I'm not happy about and what I've heard, but I do want to say there has been so much work from Ihor and SIG-PM to get where we are. If you haven't seen the machinations of feature/release product you won't know! - - -At velocity we have outgrown the notion of a central body leading. Seeing increasing cross-SIG concern where some SIGs rely on others to get their work done. - -We need to find ways to detangle those dependencies earlier. - -KEPs are focusing on enhancements, changes in ecosystem. A feature has a connotation of being user facing or interactive. KEP can be for something contributor facing, doc facing transparent. Get out of mindset we're delivering a "thing" - we're delivering value to user, contributor community, or both. - -Currently the process is cumbersome. We want to follow agile principles about local control, local understanding, sharing amongst teams. - -### The steel thread - -KEP provides opportunity for "steel thread" of custody. A KEP, as a living Markdown doc with metadata, lets you see high level idea at any group of time. A SIG can break this down into meltable ideas for each release. A KEP can last multiple milestones. In terms of features/issues, defined by SIGs, issue should be actionable. If a SIG writes an issue for that release milestone it should be approachable by any contributor who is a SIG member. - -PRs roll up to the issue: links to this issue, which links to this KEP. For the first time we would be able to see at the PR level, what the grand scheme behind everything we do, is. Not heavyweight - just linking of issues. Limit administrivia, paperwork to delivery value. - -Q: - -* For CloudProvider - discovery, had an idea, people started digging in; how do you keep updating the KEP? Do you update as you go, you odn' tknow what you need? - - * Yes, it's a living doc first and foremost. Has metadata (alpha, beta, GA). The issues worked on per milestone - say you pick 3, you document those issues; if during the course of the PRs to complete those issues you realise it's a misstep, you close the issue, you update the KEP, say you're modifying this; look at prior versions to see what it looked like before/what it looks like now. As you move to next release milestone the issues reflect that change: in terms of KEP, issues, planning. - -* Give an analysis on why issues in feature repo didn't solve this problem and why KEPs will? - - * From features standpoint: SIGs interacted with features only when they had to. By trying to keep all that info separate from PRs, issues in each milestone: no way to tie that work back to the feature issue. No way to easily understand where in this features repo issue, long if multi-milestone: where was work, and the link to the issue? Eliminate the work - - * KEP is not solving that problem. KEP is saying "how do we best define and discuss the value we're adding to the ecosystem". Learns from patterns and antipatterns of other communities. - - * Features process is central body of people not doing the work. - - * Some friction with the GitHub mechanics of issues, relabeling quarterly, etc; would be nice to keep pace with the number of issues. Moving to files to provide value will help make that clearer. - - * Managing issues in the features repo: hundreds of issues from the last year, created spreadsheets etc. Bringing value but consuming extra resources. Not synced with features repo. Good we have a spreadsheet, but difficult to manage. - - * Started going through this process in SIG-Cluster LIfecycle: replacing GitHub thread (no one updates top) with a living document (use git history for mutations; see concise summary) - think it will be a huge improvement. - - * KEPs are in Google Docs now, haven't converted to PRs - -* Does this mean the features repo is going away? - - * "Yes, eventually". - -* We need clear communication about where we are in this process. Are KEPs required, encouraged, etc? Trying with one project, be useful to know what the granularity is. - - * "It's in Alpha now" - trying to validate some assumptions. - - * Has momentum with SIG-Arch and SIG-PM - - * Assumption we will try and see if it works. - - * Want to steward people into trying it to see if it's valuable. If not, how do we make it so? - - * Community size and velocity now makes it difficult to radiate information to get what you need to know. - - * Kubernetes 1.10 would be a great place. - -* Will it still be true in 1.10 that you need features? Can you have KEP instead of a Feature issue? Make it very obvious for 1.10 please. - - * One thing we need to sort out - - * 1.10 will have existing features process - - * Cluster Lifecycle are experimenting with how to do differently - - * Would love to see SIGs try the KEP process but it's not a full surrogate for the features process yet. - -* Existing features can be sorted, filtered etc - will there be tooling around KEPs? Until that's ready, I wouldn't want to switch - - * Proposals are different to features: issues will be associated with a KEP. In some ways it will be better as it's in the repo itself. - -* How are the issues tied to the KEP? - - * Ties to this markdown file, in /kep/____ - - * We need to work out the details. - - * When I create issue template, it will have a link to that KEP. - - * *Make sure it's searchable!* - -* (Jago Macleod) Be explicit of scope of a KEP. A trend to more SIG ownership, code, roadmap etc; context is a SIG plans their own work. Certain faster moving SIGs, more capacity, to solve problems in the wrong component. Some KEPs will span SIG boundaries and should be explicit about this in comms. - -* (Tim Hockin) GitHub UX is not going to be great for this. It's not built for what we're trying to do. All of this predicates on having an actual site that manages, a web app? - -If that's true, can we start to collect the expertise? - -Is there a SaaS tool for this? - - * See other projects using tracking tooling, used on files in source control - - * Won't be pretty or searchable in first iteration. - - * Want to see built out as they're consumed. Don't build tooling before people are using the process - - * *GH search is less than usable* - - * Do you have a place to host this? We will find a place to host if someone is willing to write. Matt will help write. - - * As someone involved with Maven repositories (trello) - it's a total pain in the neck. More in favour of PRs, discoverability, etc. Keep PRs for process. Push a site for discoverability. - -* (Joe Beda) Current processes are discussion, argument, write-only: comment threads no-one reads. Make it more discoverable, more readable: check stuff into GitHub, use a static site generator, publishes it somehow, crosslinks between documents. Just like when you go to an RFC, reference one there's a link; that's the ecosystem of discoverability we want. - - * If someone comes to project and we have no way of telling what's happening. - -* (Eric Tune) I created features process so I'm a little attached. This discussion is a refactor vs rewrite debate. The feature repo template is there; in GitHub; change it. See how many incremental changes we can make to solve proposals. Put fields there and yell at people who don't fill it in. - -* (Angus, Bitnami) As someone involved in Rust community: - - * fairly well-read Rust weekly news summary, including a section with a summary on outstanding proposals, broken down into early and late discussion phases. Read late phase to see what's a done deal vs. what's up in the air. There's also a RFC podcast, where they get a couple of people, have a chat show about what's involved in that proposal. Lots of ways as a community member to stay up to date. - - * Fixed timeline: trying to get approval. If nothing happens by the end it's approved by default. - - * May not want to copy but good to know. - -* (Daniel Smith, Google) summarising: problems are mostly discoverability: we'll write tooling. Why can't we write tooling against that existing process? Both current and hypothetical new process suffer - - * Interacting with objects in GitHub is hard at our scale, we have a limited number of tokens. - - * Procedural aspects: if I look at a PR, there's a link to an issue: that will tie up to a KEP. - - * Discoverability of relationships: exposed in the API. Links on GitHub are implemented by full-text search, not hard to do this. - -* (Chen Goldberg) Schedule follow-up sometime this week - communicating is hard, we're all here! - -* (Henning, Zalando) Structured format with some metadata: all in one repo, or distributed amongst incubator projects etc? Are KEPs with a unique identity going to live in other project repos? Was this an idea? - - * Idea is to have as consolidated as possible: given committee questions of "what is Kubernetes, what follows our PM norms". Problem is visibility for people who trust workloads in the software we create. Want to provide this so someone can determine why a thing was done a certain way. Projects outside the core repo: would follow a similar process in a perfect world. - -If you're not excited about features process, try a KEP! - -Reach out to SIG-PM - calebamiles@ - -### The long view - -(Jaice) Have planning sessions about what SIGs are hoping to deliver for any milestone. Want to facility planning meetings in a more structured way (Planning as a Service). I did this for a proposal SIG-Cluster Lifecycle are working on: to have the discussion early and untangle dependencies, see when things could go off the rails, etc. Will talk to SIG leaders. - -This planning activity will be one of the key success factors for the project moving forward. - -Roadmap for 2018 (30min summary) --------------------------- - -Notes by @jberkus - -Speakers (check spelling): Apprena Singha, Igor, Jaice DuMars, Caleb Miles, someone I didn't get. SIG-PM - -We have the roadmap, and we have this thing called the features process, which some of you may (not) love. And then we write a blog post, because the release notes are long and most of the world doesn't understand them. - -Went over SIG-PM mission. We had several changes in how the community behave over 2017. We are moving to a model where SIGs decide what they're going to do instead of overall product decisions. - -2017 Major Features listed (workloads API, scalability, networkpolicy, CRI, GPU support, etc.). See slides. The question is, how did we do following the 2017 roadmap? - -Last year, we got together and each SIG put together a roadmap. In your SIG, you can put together an evaluation of how close we came to what was planned. - -Q: Last year we kept hearing about stability releases. But I'm not sure that either 1.8 or 1.9 was a "stability release". Will 2018 be the "year of the stability release?" - -Q: Somehow the idea of stability needs to be captured as a feature or roadmap item. - -Q: More clearly defining what is in/out of Kubernetes will help stability. - -Q: What do we mean by stability? Crashing, API churn, too many new features to track, community chaos? - -Q: Maybe the idea for 2018 is to just measure stability. Maybe we should gamify it a bit. - -Q: The idea is to make existing interfaces and features easy to use for our users and stable. In SIG-Apps we decided to limit new features to focus everything on the workloads API. - -Proposals are now KEPs (Kubernetes Enhancement Proposals) are a way to catalog major initiatives. KEPs are big picture items that get implemented in stages. This idea is based partly on how the Rust project organizes changes. Every SIG needs to set their own roadmap, so the KEP is just a template so that SIGs can plan ahead to the completion of the feature and SIG-PM and coordinate with other SIGs. - -Q: How do you submit a KEP? -A: It should live in source control. Each KEP will releate to dozens or hundreds of issues, we need to preserve that as history. - -If you look at the community repo, there's a draft KEP template in process. We need to make it a discoverable doc. diff --git a/community/2017-events/12-contributor-summit/feature-workflow.md b/community/2017-events/12-contributor-summit/feature-workflow.md deleted file mode 100644 index 8bb0fa47..00000000 --- a/community/2017-events/12-contributor-summit/feature-workflow.md +++ /dev/null @@ -1,85 +0,0 @@ - -Feature Workflow ----------------- - -Notes by @jberkus - -TSC: Getting something done in Kubernetes is byzantine. You need to know someone, who to ask, where to go. If you aren't already involved in the Kubernetes community, it's really hard to get involved. Vendors don't know where to go. - -Jeremy: we had to watch the bug tracker to figure out what sig owned the thing we wanted to change. - -TSC: so you create a proposal. But then what? Who needs to buy-in for the feature to get approved? - -Dhawal: maybe if it's in the right form, SIGs should be required to look at it. - -Robert B: are we talking about users or developers? Are we talking about people who will build features or people who want to request features? - -???: Routing people to the correct SIG is the first hurdle. You have to get the attention of a SIG to do anything. Anybody can speak in a SIG meeting, but ideas do get shot down. - -Caleb: we've had some success in the release process onboarding people to the right SIG. Maybe this is a model. The roles on the release team are documented. - -Anthony: as a release team, we get scope from the SIGs. The SIGs could come up with ideas for feature requests/improvement. - -Tim: there's a priority sort, different projects have different priorities for developers. You need a buddy in the sig. - -Clayton: review bandwidth is a problem. Review buddies hasn't really worked. If you have buy-in but no bandwidth, do you really have buy-in? - -TSC: The KEP has owners, you could have a reviewer field and designate a reviewer. But there's still a bandwidth problem. - -Dhawal: many SIG meetings aren't really traceable because they're video meetings. Stuff in Issues/PRs are much more referencable for new contributors. If the feature is not searchable, then it's not available for anyone to check. If it is going to a SIG, then you need to update the issue, and summarize the discussions in the SIG. - -TSC: Just because a feature is assigned to a SIG doesn't mean they'll acutally look at it. SIGs have their own priorities. There's so many issues in the backlog, nobody can deal with it. My search for sig/scheduling is 10 different searches to find all of the sig/scheduling issues. SIG labels aren't always applied. And then you have to prioritize the list. - -???: Test plans also seem to be late in the game. This could be part of the KEP process. And user-facing-documentation. - -Robert B: but then there's a thousand comments. the KEP proposal is better. - -???: The KEP process could be way to heavy-weight for new contributors. - -???: new contributors should not be starting on major features. The mentoring process should take them through minor contributions. We have approximately 200 full-time contributors. We need to make those people more effective. - -TSC: even if you're a full timer, it's hard to get things in and get a reviewer. Every release, just about everything that it's p0 or p1 gets cut, because the person working on it can't get the reviewer all of the stuff lined up. - -Caleb: you need to spend some time in the project before you can make things work. - -Dhawal: is there a way to measure contributor hours? Are people not getting to things because people are overcommitting? - -Jago: The problem is that the same people who are on the hook for the complicated features are the people who you need to review your complicated feature. Googlers who work on this are trying to spread out their own projects to that they have more time at the end of the review cycle. - -Jaice: If you're talking about a feature, and you can't get anyone to talk about it, either the right people aren't in the room, or there just aren't enough people to make it happen. If we do "just enough" planning to decide what we can do and not do, then we'll waste a lot less effort. We need to know what a SIG's "velocity" is. - -Connor: the act of acquiring a shepard is itself subject to nepotism. You have to know the right people. We need a "hopper" for shepherding. - -Tim: not every contributor is equal, some contributors require a lot more effort than others. - -Robert: A "hopper" would circumvent the priority process. - -Josh: there will always be more submitters than reviewers. We've had this issue in Postgres forever. The important thing is to have a written, transparent process so that when things get rejected it's clear why. Even if it's "sorry, the SIG is super-busy and we just can't pay attention right now." - -Dhawal: there needs to be a ladder. The contributor ladder. - -TSC: a lot of folks who work on Kube are a "volunteer army." A lot of folks aren't full-time. - -Caleb: there is a ladder. People need to work hard on replacing themselves, so that they're not stuck doing the same thing all the time. How do you scale trust? - -???: Kubernetes is a complicated system, and not enough is written down, and a lot of what's there we'd like to change. It's a lot easier for a googler to help another googler, because they're in the same office, and the priorities alighn. That's much harder to do across organizations, because maybe my company doesn't care about the VMWare provider. - -Jaice: for the ladder, is there any notion that in order to assend the ladder you have to have a certain number of people you shepherded in? There should be. - -TSC: frankly, mentoring people is more important than writing code. We need to bring more people into Kubernetes in order to scale the community. - -Josh: we need the process to be documented, for minor features and major ones. Maybe the minor feature process belongs to each SIG. - -Jaice: the KEP is not feature documentation, it's process documentation for any major change. It breaks down into multiple features and issues. - -???: The KEP needs to include who the shepherds should be. - -Clayton: reviewer time is the critical resource. The prioritization process needs to allocate that earlier to waste less. - -Jeremy: the people we sell to are having problems we can't satisfy in Kubernetes. We have a document for a new feature, but we need every SIG to look at it (multi-network). This definitely needs a KEP, but is a KEP enough? We've probably done too much talking. - -Clayton: the conceptual load on this is so high that people are afraid of it. This may be beyond what we can do in the feature horizon. It's almost like breaking up the monolith. - -Robert: even small changes you need buy-in across SIGs. Big changes are worse. - -Connor: working groups are one way to tackle some of these big features. diff --git a/community/2017-events/12-contributor-summit/kubernetes-client-libraries-open-space.md b/community/2017-events/12-contributor-summit/kubernetes-client-libraries-open-space.md deleted file mode 100644 index d23327d2..00000000 --- a/community/2017-events/12-contributor-summit/kubernetes-client-libraries-open-space.md +++ /dev/null @@ -1,68 +0,0 @@ -_Notes from the open space discussion at the Kubernetes Contributor Summit 2017 lead by @brendandburns_ - -Three high-level topics: - -* Client libraries and autogeneration -* OpenAPI description status -* Fluent libraries (ie. those with native sensibilities) - is this scalable given need for lots of hand-written code? - -Early shout-out for the [Common LISP client](https://github.com/brendandburns/cl-k8s) :) - -Currently Java, Python, .Net, Javascript clients are all silver. Reference to the [badge and capabilities descriptions](/contributors/design-proposals/api-machinery/csi-new-client-library-procedure.md#client-capabilities) -Python still outside the [clients org](https://github.com/kubernetes-client/) - should this move from incubator? - -Lots of code in client libraries to handle limitations in OpenAPI 2, some of which is fixed in 3. What is required/should we move to OpenAPI 3? - -The Go client is a special case, predates the swagger work and bypasses the autogeneration. This leads to it being an odd first-class citizen. - -Noted that currently client libraries generated against specific version of API -> “I can’t currently write a library which supports multiple versions of the API from the same client” - -Discussion of packaging. Should clients be packaged as one thing (with support for multiple versions in subpackages) or with each package representing support for a specific version? - -Autogeneration is desirable, given the wide number of languages. But what should be the canonical description. Noted that -go-restful, which is currently in use, (starts from Go) vs go-swagger (which starts from an OpenAPI description), worthwhile discussing which mode would work best now. - -Would it be possible to annotate the Go types to avoid some problems in the generator code? - -The API documentation is currently poor, mainly non-language specific API documentation. - -What kind of examples do we expect for each client? It would be great to create a set of canonical usecases for clients and for each of them to have (maybe autogenerated) examples for each. - -There are some Client Guidelines, @mbohlool would have a link? - -Note that the websockets protocol is under-documented. Kubernetes Java client has a description of the protocol and is the best place to look for details. - -SPDY still in use. Should this be deprecated? - -Question about what additional clients, or improvements, people would like to see: -* A smaller Go client -* Rust -* C++ - -Informers, should this be part of the API and available so as to be easier to use from other languages? This is not currently part of the client capabilities set mentioned above. We’re probably better off building a generic multiwatch controller than supporting the informers in all other client libraries. - -Service Catalogue and other extension points. Advice is to use the generator tools to generate your own clients. See [kubernetes-client/gen](https://github.com/kubernetes-client/gen) - -There is a plan to split the go client in to two - one hand rolled, one autogenerated. - -API supports proto as a wire format, but client generation here is hard. The protocol doesn’t know the path to which it needs to be sent. Protos are also generated from the Go structs. - -At least have a common language for description APIs. Proto vs Go. - -Worth noting that kubernetes-client is actually relatively low barrier to entry for getting started contributing to Kubernetes. We should talk about that more publicly. - -Discussion of issues with kubeconfig. - -* There is no spec for kubeconfig? -* One proposal, move folks to kubeconfig.d (ie. one config file per cluster) -* No clients support (apart from Go) support merging kubeconfigs. -* Problem with changes here is the large number of kubeconfigs in existence. -* Can we have a new config file format (v2) which exists alongside the existing one. - -Noting that kubeconfig contains several things, which arguably shouldn't be as closely coupled. - -* Identities -* List of clusters -* Namespace -* Current context diff --git a/community/2017-events/12-contributor-summit/onboarding-new-developers-through-better-docs.md b/community/2017-events/12-contributor-summit/onboarding-new-developers-through-better-docs.md deleted file mode 100644 index ddb6d688..00000000 --- a/community/2017-events/12-contributor-summit/onboarding-new-developers-through-better-docs.md +++ /dev/null @@ -1,232 +0,0 @@ -Onboarding Developers through Better Documentation - -@ K8s Contributor Summit, 12/5 - -Note Taker: Jared Bhatti ([jaredbhatti](https://github.com/jaredbhatti)), Andrew Chen ([chenopis](https://github.com/chenopis)), Solly Ross ([directxman12](https://github.com/DirectXMan12)) - -[[TOC]] - -### Goal - -* Understand how we’re currently onboarding developers now - -* Understand the "rough edges" of the onboarding experience for new users - -* Understand how we can better target the needs of our audience - -* Understand if our contributor process will meet the documentation needs. - -Note: the focus is on documentation, so we won’t be able to act on suggestions outside of that (but we will consider them!). - -### Initial thoughts - -* Where we were at the beginning of the 2017: ([@1.4](https://v1-4.docs.kubernetes.io/docs/)) - -* Where we are now: ([@ 1.8](https://kubernetes.io/docs/home/)) - - * We are tied into the launch process - - * We have analytics on our docs - - * We have a full time writer and sig docs contrib group - - * Everything is in templates, we have a style guide - - * Better infrastructure (netlify) - -### Meeting Notes - -* Introductions - - * Jared: SIG docs maintainer - - * Andrew: SIG docs maintainer, techwriter - - * Radika: 1.8 release team, SIG docs member - - * Phil Wittrock: interested b/c it determines how system is used - - * ?? - - * Paul Morie: interested b/c hit challenges that could be avoided with better dev docs (patterns used in Kube can’t be easily found on internet) - - * Nikita: work on CRDs - - * ??: docs are a good intro to core Kube codebase - - * Michael Rubin - - * ??: dashboard contributor, onboarding is a key part of the dashboard experience - - * Steve Wong: storage SIG, on-prem SIG, trying to get head around on-prem, docs geared towards cloud - - * Solly Ross (@directxman12): want to avoid changes to fiddly bits confusing people - - * Morgan Bauer: had issues with people changing fundamental bits out from under other contributors - - * Sahdev Zala: docs are important for new contributors, first place they look, contribex - - * Brad Topol: like explaining stuff, kube conformance WG - - * Tomas: working on side project, looking for inspiration on docs for that - - * Garrett: ContribEx, looking to reduce the question "how do I get started" - - * Stefan (@sttts): where do we push docs changes to mechanics - - * Josh Berkus: ContribEx - -* contributor docs - - * Avoid the process for finding which of the 49 people have the right info 6 months after it merges - - * Have contributor docs which merge with "internal features" (e.g. API registration changes) - - * Have a flag for internal release notes, bot which checks - -* Issue: opinion: we don’t want to write dev docs because they’ll change - - * Issue is it’s hard to capture every little thing - - * Good start is documentation on generalities (80%/20%): e.g building an API server - - * Started out with no docs on how to do that (has gotten better) - -* Big concepts don’t change a lot, describe those - - * Ask questions: - - * What are the big nouns - - * What are the big verbs for those nouns - - * How are the nouns relate - - * Don’t fall into trap of (for example) tracepoints (accidentally creating a lot of small little fiddly points) - -* Need a way for "heads up this is changing". If you have questions, ask these specific people. - - * Very SIG dependent (some do meetings, others mailing-list focused, some have a low bus number) - -* How is your SIG interacting with docs - - * Service Catalog - - * In docs folder - - * How do we interact with docs - - * Depends on moving into kubernetes org - -* Issue: lots of docs with bits and pieces - - * Not organized into "as a developer, you’re interested in these links" - - * Spend a week, come up with a ToC - - * Many docs in different repos - - * Should have guidelines on where to put things - - * Should have templates for how to write different types of docs - -* Issue: wrong abstraction layers are exposed - - * Documenting a complex system has less payoff than simplifying - -* Issue: extending Kube blurs the line between contributor and user - - * Put more docs into the same place - - * "Crafting User Journeys": user stories buckets: Customer User Journeys ([project](https://github.com/kubernetes/website/projects/5)) - - * Need champion for different personas - -* Issue: people (e.g. Storage SIG) want to write docs, but they don’t know where to start - - * Both contributors and users, and both (plugin writing, for example, or how to provision storage securely) - - * Templates/guidelines mentioned above may be helpful - - * Talk to SIG docs (SIG docs wants to try and send delagates to SIG, but for now, come to meetings) - -* Question: should there even *be* a split between user and contributor docs? - - * No, but we have historically (didn’t used to have person-power to implement it) - -* Onboarding docs push for 2018 - - * Point people from moment one to start understanding how to contribute (design patterns, etc) - - * How do we organize, make things findable - - * How do we organize allowing people to contribute right now - - * Main site is all user docs right now - - * Starting to look at auto-import docs - - * User journeys project (above) - - * Testing right now - -* Lots of people writing blog posts - - * Any way to aggregate to some of that? - - * Wow to avoid "this doesn’t work anymore"? - - * There is a Kubernetes blog, being migrated under k8s.io - - * People can contribute to the blog for ephemeral stuff - - * We guarantee that k8s.io stuff is updated - - * For blogs, put a "sell-by date" - -* Request: join dashboard conversation - - * How do we link from dashboard to docs and vice-versa - -* Question: where do the docs of tools like kops fit in - - * More broadly hits on Kubernetes "kernel" vs wrapper projects - - * Right now, it’s checked into repo, so it should have docs on the main site - - * Documentation is endorsing, at bit - - * (but why is kops checked into the repo as opposed to other installers) - - * Have a easy way for projects (incubator and main org) to have their own docs sub-sites (e.g. gh-pages-style for the Kubernetes sites) - -### Follow-Ups - -* Suggestion: Presentation on how to structure site, write docs, user studies done, etc (why are Kube docs the way they are) - - * "I want to get started fast" - - * "I want to build the next thing that gives me value" (task-driven) - - * "Something broke, where’s the reference docs" (troubleshooting) - -### Projects In Development - -* Customer User Journeys ([project](https://github.com/kubernetes/website/projects/5)) - -* Revamp of [docs landing page](https://kubernetes.io/docs/home/) - -* Building out a glossary ([project](https://github.com/kubernetes/website/issues)) - -* More doc sprints ([like this one](https://docs.google.com/document/d/1Ar4ploza6zA1JF3YO4e0lzq1RRBWWx8cAZtRQMMEdsw/edit)) - -### Continue participating! - -* Content exists under [Kubernetes/website](https://github.com/kubernetes/website) (feel free to fix an issue by [creating a PR](https://kubernetes.io/docs/home/contribute/create-pull-request/)) - -* Join the [kubernetes SIG Docs group](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) - -* Attend the next Kubernetes docs community meeting (Tuesdays @ 10:30am, PST) - -* And join the kubernetes sig-docs slack channel ([kubernetes.slack.com](http://kubernetes.slack.com/) #sig-docs) - diff --git a/community/2017-events/12-contributor-summit/role-of-sig-lead.md b/community/2017-events/12-contributor-summit/role-of-sig-lead.md deleted file mode 100644 index 54e3d26f..00000000 --- a/community/2017-events/12-contributor-summit/role-of-sig-lead.md +++ /dev/null @@ -1,110 +0,0 @@ -# What is the role of a sig lead -*Notetaker: @MHBauer* -Lots of sig leads are present in the room - -If there is a doc it’s years out of date - -Joe wants to redefine the session -Power and role of sig leads is defined in how we pick these people. Voting? Membership? What do we do for governance in general - - -Paul: Roles that are valuable that are not sig lead. Svc cat, moderator of discussions and took notes. Secratary of committee. - -Back to joe; what does the sig think. Each leader doesn’t know. Who shows up to a meeting isn’t helpful as not everyone can attend. What does the lead thing? Allows too much personal power. Decision maker or tech lead? - -Meeting form last year is that sig lead was facilitator. Have been more tech leads now. Sig leads got invites to the contributor summit. - -Erik from testing. Failures in tests associated with a sig lead to no accountability by a sig member. Assigned the label to the sig with no action afterwards. Need accountability from the sigs or the leads to get testing failures cleared - -Owners files, maintainers, approvers, of particular parts of the code base. As a sig lead. Mostly doing facilitating, and not touching the code. Owners files own the codebase. Not the leads of the sigs. Sig leads elevate problems to the people in the owners files. - -Daniiel smith - api - would not be helpful to have a facilitator, mostly very technical details. - -Paul, tech vs facilitator fulls you in different directions. Facilitator with an agenda is a dictator. If you have a tech agenda, you should not try to lead all the meetings. Meeting facilitator role that aaron did, operated the meeting agenda. Hands to talk. Stopped advocating for techical topics, and mainly doing moderation. Everyone else focuses on technical topics. - -Joe - 3 roles, process facilitatior, technical facilictator, techincal design and lead. Implication that the process leader is not technical. Build consensus vs “we’re doing it this way” - -Down - on sig node. Facilitatior and tech lead. Detach from. If she doesn’s make the agenda there is not one. - -Joe -need someone who cares - -Eric chang - every sig needs a person doing X,Y, Z. docs, tests, etc. fundamental goals. Sig lead has too much to do. Formalize roles and fill them with people, especially different people for each role. -Large sigs have more people to allocate to alt roles. - -Jessie - Can’t have the person who facilitates be unbiased techincally. Best solution vs alternative monetary gain. - -Joe - people as sig leads in name only to game the system as being important - -Erik - adding or retiring members. - -Do any sigs have an election process? Not that we know of. Sig node has a rotation. One member retired as they moved from working on the open source to working on their internal system. Some people turned down a lead, based on the involvememt necessary. - -Sig leads should already should be fulfilling the role, vs assigning titles and duties to expect - -Define roles, and all sigs must provide names. - -Document process for how to choose role. Fair and equitable. A generic process that’s generic. - -People in the sig decide. Who’s in the sig? How do we say a sig or sig member is doing a bad job? - -How to decide who gets to decide? - -Which things does a sig own. People own things, not sigs. With a document proposed to assess new owners. Subteams and persons. - -People who have non-code duties, but are also still participants and lead-worthy. - - Does sig-pm write any code? - -Long term sigs own artifacts. They own process and have long term documentation. - -Things not in kubernetes/kubernetes don’t have necessarily an ownersfile. - -Everything should role up to a sig. - -Owners cut across a project and end up having a person with lots of power vs a sig. - -Sigs and humans as owners. - -Erik f - Tests assigned to owners seems to be a fialure. A sig having a dashboard seems successful. The sig being responsible seems successful, not a person responsible. Things assigned to sigs, not to people. - -Suggestion of a person on a single sig. Limits. Pick what you find important, commit to it. -Might be career limiting if you can olnly work on one thing. -Doubts of same person leading multiple sigs. -Leading a sig vs participating. -Multiple roles again. - -Sig lead, to facilitate, sig pm representative to put technical demands and objectives to the wider community. -What to do when they fail? -Separation of powers. Do we have it now? Are the people who lead a meeting the people who code and merge and approve. - -Joe - gut check summary -Set of roles to nominate -Clear lines of sight which owns what code -Some are large and may have subdivisions (do people own code or do groups) -Starting point for sigs -Everyone should document the process and how it got that way -Possible future date to reboot the sigs. Evolution vs revolution. Merge and split. -Sig lead retired in frvor of multiple roles. “Lead” creates perverse incentives. Roles with terrible titles. POLITICS! - -Find a set of roles. - -What’s the bar to form a sig? -If I want to have a component, I need a sig! - -Retire and merge some sigs. Sig for each cloud and a common cloudprovider and a cross-cloud sig. -Cluster-lifecycle plus cluster-ops - -Daniel - avoid selecting process followers, not for decision making skills. Avoid over specifying. - -Joe - We need to expect some responsibility from the sig to the rest of the project. Avoid overfit. - -Associate owners files with sigs, maintainers vs sig leads. Contributor ladder is disorganized. Owners contributors maintainers. - -4 minutes. -Work with the steering committee to work this out. Steeering committee has to do this to help this make. - -Hard to participate in some sigs, -Suggestion of office hours - -Spotty communication of what a sig is doing. Authority and responsibility of what to communicate what a sig is doing. - diff --git a/community/2017-events/12-contributor-summit/scaling-new-contributors.md b/community/2017-events/12-contributor-summit/scaling-new-contributors.md deleted file mode 100644 index 925e18ac..00000000 --- a/community/2017-events/12-contributor-summit/scaling-new-contributors.md +++ /dev/null @@ -1,61 +0,0 @@ -# Scaling New Contributors -*Lead: Vishnu Kannan* -*Notetaker: Chris Love* - -New pull requests are plateauing in k/k -Takes much longer for a PR to get through - -Contributor Experience -3 mo for PR merged - minor PR that was a fix -Nobody reviewed - was ignored -PRs are lacking process to get them on milestones -Lack of organization and understanding PR process -There is a need for a sig buyin -We have a explicate state machine, instead of a implicate state machine -We do have a well defined process for new contributors to follow -We need to have committed resources to a PR, -File an issue first, then file a PR -When the needs sig is there, the issue will be processed and you can find out which sig - -What is the problem -No time to review PRs - -Mentoring Program -Mentoring program overview -Common theme is that we do not have time to review PR -Bootcamps for new contributors - -Lot of Common Complaints - -Tests did not pass what happened -Devstats -Everyone needs to look at the stats -We are currently bottlenecked at approvers not reviews - -How to fix the problem -SIG Leads are too busy -Have another role within the sigs for mentors -Can we label the issues in terms of complexity -Sig-cli has it documented in a contributor guide -Incentivizing mentoring -How do we help take the load off of the approvers pool, how do we improve reviews -How many times a reviewer say lgtm -Reviewer performance -We need to document what a good review looks like -Guidance on progress to contributor -> reviewer -> maintainer -How does maintain a good citizenship in the community -Put the documentation into kubernetes.io -Simple use-case examples on how to get a PR in -Give contributors some responsibilities -Planned workshop on how to get a PR merged -Contributor based workshop -Ask questions on #kubernetes-dev -We need to document how to get answers -We need to move our documents into kubernetes.io -Sigs may not want to have new contributors -We need to cleanup those who are inactive in k/k - OWNERS and MAINTAINERS -How do we create incentives? -If they are autosigned an issue and do not respond - we need to measure that metric -How do we fix the release process in terms of what is in a release, because we do not have a target we do not know what we are shooting at -We need to figure out what new contributors are working on -Start off by using kubernetes then become contributors diff --git a/community/2017-events/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md b/community/2017-events/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md deleted file mode 100644 index d7f3e3a0..00000000 --- a/community/2017-events/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md +++ /dev/null @@ -1,104 +0,0 @@ -# Scaling Up & Scaling Down & Addon Management Session… - -Notes by @justinsb - -## Scaling Up & Scaling Down - -Lots of users that want to run on a single node cluster - one node, one core -thockin’s position: 1 node 1 core should continue to work (with 3.75GB, but ideally less than 2GB) -Works today but only just - e.g. you only have 0.2 cores left today -Addons / core components written with a different target in mind -Some of the choices not optimal for single node (e.g. fluentd / ES) - -Cluster Proportional Autoscaler tries to solve this - Targets a daemonset / deployment and changes number of pods - -CPVPA Cluster Proportional Vertical Pod Autoscaler - Applies a step function based on the number of cluster cores to change the resources needed by a target deployment / daemonset -Prototype being used today in GKE for calico - Needs a pod per target which leads to higher resource usage - Idea: to have a single pod that uses a CRD to amortize the costs across multiple targets - Problems we want to address: - We want more granularity at the low end, both because it matters more proportionately - We want to avoid constant rescaling - changing resources requires restarting pods - -Q (solly): What is missing from kubernetes today - what is different vs generic HPA/VPA? Why can’t I reuse the existing HPA/VPA? How do I tell the difference from a UI perspective? -A (thockin): We could wrap the autoscaler; or we could have a ref pointing back up; or we could integrate back into HPA/VPA. The third option is mostly what we’ve encouraged - where things are proved out of tree and then merged back in. - -Some changes needed in HPA/VPA - pulling in metrics from a different source e.g. number of cores in cluster. (Do we need a “count” API) - -Q (clayton): Does this indicate that requests / limits are “broken”? Should we instead be thinking about e.g. overcommit to deal with smaller sizes. -A (thockin): No - the step function is defined by the author of e.g. kube-dns based on their knowledge of the requirements. And this is typically for “fundamental” components, not user applications, and so the broader question for users is separate. - -Q (gus): We need to consider architectures (e.g. 64 bit might use more memory). Are we wasting more memory running a pod to right-size the other pods? -A (thockin): That’s why we want one pod with a CRD, but yes … we want to fold it back in. but we have to prove it first. - -Q: Why can’t this be done in e.g. kubeadm -A: Because clusters change size - e.g. cluster autoscaler - -Q (jago): Focusing on small clusters - we should come up with clear guidance for resource requirements. Maybe we need T-shirt sizes which helps us figure out what we can run in various clusters. -A (thockin): We need to start collecting data - that’s part of this effort. - -Q (vish): Is kubernetes the right approach for small clusters -A: Yes! Yes! Yes! Lots of resounding yeses - devs want to run on their laptops, people happily run personal clusters on single nodes etc. - -Q (dawn): It is hard to come up with a single scale function - e.g. with docker on the node team the kernel options have a big impact. But we should still provide a scaling function as a guide, and to allow for operators to tweak it - -Q (chrislovecnm): Key point - we must collect data! - -Q: There is a lack of documentation on resource requirements e.g. memory requirements of apiserver at various sizes. - - -## Add-on Management - -It’s been the can that’s been kicked down the road -Questions: - What is an addon? - Kubeadm says kube-dns, kube-proxy - GKE adds dashboard & heapster - -Thockin: Addons are things we manage vs things you manage. We = administrator, you = User - -Luxas: kubeadm installs minimal addons to get conformance to pass - -solly: Important not to conflate addons with discussion of what is core vs not - -Clayton: Is Istio an addon? What if it becomes super-complicated... - -Mrubin: 3 categories of addons: - Istio, Service Catalog, Service Broker - Network policy - Kube-proxy and kube-dns -Sniff test: Does it have to be tied to a version of kubernetes? - -Robertbailey: Maybe addons should be the minimal set of things required to pass conformance - -Chrislovecnm: What’s our goal - we want something to install a manifest on the cluster? - -Clayton: the challenge isn’t installation - it’s upgrades / updates. Are we really ready to manage this? Addons should be things that we can actually manage, including addons. - -Thockin: we want a simple solution, not a full solution for arbitrarily complicated applications. - -Jago: We want a set of components that as a platform operator we install and upgrade/version together and validated together, and cluster-level. This is distinct from user applications or even application etcd. - -Bboreham: cross-grade between alternatives is a related aspect - e.g. swap out implementation of network policy. In practice today you have to reinstall the cluster, because otherwise it requires the network policies to cooperate. - -Clayton: comparison to runlevels - where it’s very possible to brick your cluster by doing things out of sequence. - -Gus: The installation tools do all differ in what addons they are installing (e.g. AWS and GCE have very different requirements). So the installation tool will have opinions here - what value are we adding? - -Thockin: There is an opportunity here to define something cross-cutting - “apt or yum for kubernetes”. Having each installer do something different is not great. - -Clayton: apt or yum doesn’t get you all the way - you still need to tweak configurations. - -Mrubin: Kubernetes is a bunch of small pods cooperating. The mechanism is the same for installing DNS as it is for network policy - which is good in that we have a harmonized approach. We want to figure out the mechanism by which components can be packaged by authors, discovered, and integrated by installers. - -Mrubin: There is a belief that some pods in kube-system are special - -Dawn: The kube-system namespace is known to be system-managed / updated and critical pods - even if it isn’t actually special in a technical sense. - -Jess: We want to avoid decision paralysis. And there’s odd incentives where people want to monetize their code or their approach. We have to limit the scope as much as possible. - -Robertbailey: Agreed - we have to scope this just to the minimal components needed to install stuff. And then users can install more opinionated things like helm. - -Thockin wrapping up: Still an open question of what we should do here, how the various distributions should avoid duplicating effort. diff --git a/community/2017-events/12-contributor-summit/schedule.png b/community/2017-events/12-contributor-summit/schedule.png deleted file mode 100644 index 03942e5d..00000000 Binary files a/community/2017-events/12-contributor-summit/schedule.png and /dev/null differ diff --git a/community/2017-events/12-contributor-summit/should-k8s-use-feature-branches.md b/community/2017-events/12-contributor-summit/should-k8s-use-feature-branches.md deleted file mode 100644 index f8af5427..00000000 --- a/community/2017-events/12-contributor-summit/should-k8s-use-feature-branches.md +++ /dev/null @@ -1,113 +0,0 @@ -# Should Kubernetes use feature branches? - -Lead: Brian Grant - -Note Taker(s): Aaron Crickenberger - -Focusing on our current release cadence: - -- We spend several weeks putting features in -- We spend several weeks stabilizing the week kinda/sortof - -The people who are managing the release process don’t have the ability to push back and say this can’t go in and we don’t want to slip the release so they’re left powerless - -In earlier session today over breaking up monolith: - -- We have over 90 repos -- The releases are getting bigger and more complex -- Not everything we’re moving out of the monorepo, not everything makes sense - -What do we do about those things -I think the only way we can get out of the release fire drills is to have an earlier gate - -Q: Aaron: Why not use the tests we have today and push back saying the tests have to be green? - -- A lot of the new features have inadequate testing or inadequate features -- We want to continue to release on a regular on cadence -- Use some model like gitflow that puts feature work into feature branches before they land into master -- I think we need to allow features to be developed in feature branches instead of landing in kubernetes/kubernetes master -- But we also can’t have large monolithic feature branches -- Because one thing going in might cause rebase hell for other things going in -- Test machinery is getting to a point where it can use branches other than master to spin up tests -- You can spin up a feature branch and get tests running on it without too many issues -- I think we have to do within either 1.10 or 1.11 release - -Q. I heard two 2 concerns: - -- How do you protect mainline development from these features going in? -- How do you know when they’re ready to go in? -- So nodejs claims to have something like 90-something% coverage, we don’t even have coverage measurement -- With the interdependence of everything in the system it’s basically impossible to back changes out - -Q: (thockin) -How do we think we can do this across repos? - -- Can we hear from people who have actually tried this for what the pain points are? -- There are lots of details to work out and people are just going to have to try it at small scale and then at large scale -- A lot of the times people try to get their foot in the door with tiny feature PR’s, and then docs, and then feature completion -- Jan commenting on experience with workload api’s -- Tried bumping workload api’s from v1beta2 to v1, tried it on feature branch -- Main blocker was tests, tests weren’t running against the feature branch, only the master branch automatically -- We decided we were just going to do it directly against the master branch - -Q (spiffxp) How do we prevent merge chicken, aka racing to get in so you don’t have to avoid rebase hell - -- With api machinery, one thing we’ve done is wait until after the release cycle to minimize the amount of time that people have to do rebasing -- We scheduled that massive change to land right after code freeze -- Re: how do we prevent once you’re in you’re in… that’s basically the way it goes right now - -Thockin: - -- the pattern that I see frequently is somebody sends me a 10k line PR and I see please break this up and they do, but then they forget the docs and somewhere along the way we miss it -- Bgrant: it’d be great if we could ask people to write the docs first (maybe this is a criteria for feature branches) -- Venezia: what about having a branch per KEP? Also, facebook does something like feature flags, is that something we could do or is that just impossible? - -Bgrant: - -- That can be used, but it requires a huge amount of discipline to ensure those flags are used correctly and consistently throughout the code -- Some features we can easily do that eg: if it’s an API, but it’s much harder to do with a feature that’s threaded through components -- A branch per KEP is roughly the right level of granularity -- What’s the difference between a feature branch and a massive PR? -- Review flow isn’t well suited to massive PR’s -(thockin) It’s easier on maintainers if we get things in and lock them in, but not on the main tree -(thockin) one thing I like about the linux kernel model is the lieutenant model - -Q: (maru) you’re still going to have to rebase feature branches the way that you rebase PR’s right? - -- A (jago) the difference is that a whole team could work on a feature branch -- I like the idea of trying a few projects and then reporting back -- I think roughly the level of granularity of having a branch per KEP sounds about right -- Multiple feature branches affecting the same area of code would be a very useful place to get some infromation - -Q (???) if someone needs to rebase on a feature branch, could it instead be resolved by a merge commit instead? - -- (thockin) I think we could solve that with technology and it could be better than building a better review tool -- Rebasing sucks, part of the reason we have that is generated code, part of it is poor modularity -- We could stand to expend some energy to improve modularity to reduce rebases -(bgrant) either feature branches or moving code to other repos are forcing functions to help us clean some of that up - -Q: how do we make sure that when issues are filed people know which commit/feature branch they should be filing against? -- (bgrant) I suspect most issues on kubernetes/kubernetes are filed by contributors -- (jdumars) imagine you have a KEP that represents three issues, three icecubes you’ve chipped off the iceberg, the feature branch would hold code relevant to all of those issues -- (luxas) feature branches should be protected - -Yes we’ll definitely want a bot that automatically -Q: (alex) do we want to have feature branches -Q: (thockin) why not just use a fork instead of branches? - -- I think it’s harder to get tests spun up for other users -- (jgrafton) worry about adding yet another dimension of feature branches to our already large matrix of kubernetes and release branches - -- Not so much for PR’s, but for CI/periodic jobs -- You need to run more than just the PR tests -- The experience with gated features is that tests do run less often, so racey bugs that pop up less frequently get exposed less often; so there is a concern that we wouldn’t get enough testing coverage on the code -- We’ll figure out what the right granularity is for feature branches is, probably shorter than a year, but probably shorter than a year -- One idea is instead of support forks to users, what if we forked to orgs owned by sigs, and just made sure the CI was well setup for those orgs? -(ed. I’m nodding my head vigorously that this is possible) -- Just another comment on branches on main repo vs. in other repos -- The branches in the main repo could be another potential for mistakes and fat fingers that we could be better solve by making the tooling work against arbitrary repos -- (jgrafton) related to the ownership of e2e tests and the explosion of stuff.. Do we expect sigs to own their tests across all feature branches? - Or should they only care about master - -Q: worry about tying feature ownership too closely to a single sig, because features could involve multiple sigs - -If you want to get started with feature branches, reach out to kubernetes-dev first and we’ll get you in touch with the right people to get this process started diff --git a/community/2017-events/12-contributor-summit/steering-committee-update.md b/community/2017-events/12-contributor-summit/steering-committee-update.md deleted file mode 100644 index 3c2f0a92..00000000 --- a/community/2017-events/12-contributor-summit/steering-committee-update.md +++ /dev/null @@ -1,47 +0,0 @@ -Steering Committee Update --------------------------- - -Notes by @jberkus - -Showed list of Steering Committee backlog. - -We had a meeting, and the two big items we'd been pushing on hard were: - -* votining in the proposals in the bootstrap committee -* how we're going to handle incubator and contrib etc. - -Incubator/contrib: one of our big concerns are what the the consequences for projects and ecosystems. -We're still discussing it, please be patient. In the process of solving the incubator process, we have to answer -what is kubernetes, which is probably SIGs, but what's a SIG, and who decides, and ... we end up having to examine -everything. In terms of deciding what is and isn't kubernetes, we want to have that discussion in the open. -We also recognize that the project has big technical debt and is scary for new contributors. - -We're also trying to figure out how to bring in new people in order to have them add, instead of contributing -to chaos. So we need contributors to do mentorship. We also need some tools for project management, if anyone -wants to work on these. - -We're also going to be working on having a code of conduct for the project, if you -want to be part of that discussion you can join the meetings. For private concerns: steering-private@kubernetes.io. -One of the challenges is deciding how enforcement will work. We've had a few incidents over the last 2 years, -which were handled very quietly. But we're having more people show up on Slack who don't know norms, -so feel free to educate people on what the community standards are. As our project expands across various -media, we need to track the behavior of individuals. - -Q: "Can SIGs propose a decision for some of the stuff on the backlog list and bring it to the SC?" -A: "Yes, please!" - -The other big issue is who owns a SIG and how SIG leaders are chosen. The project needs to delegate more things to the -SIGs but first we need to have transparency around the SIG governance process. - -Q: "As for What Kubernetes Is: is that a living document we can reference?" -A: "There's an old one. I have a talk on Friday about updating it." - -There's also the question of whether we're involved in "ecosystem projects" like those hosted by the CNCF. Things will change -but the important thing is to have a good governance structure so that we can make transparent decisions as things change. - - - - - - - diff --git a/community/2017-events/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md b/community/2017-events/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md deleted file mode 100644 index b2f202b3..00000000 --- a/community/2017-events/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md +++ /dev/null @@ -1,62 +0,0 @@ - -What's Up with SIG-Cluster-Lifecycle ------------------------------------- - -Notes by @jberkus - -Luxas talking: I can go over what we did last year, but I'd like to see your ideas about what we should be doing for the future, especially around hosting etc. - -How can we make Kubeadm beta for next year? -Opinions: -* HA - * etcd-multihost - * some solution for apiserver, controller -* Self-hosted Kubeadm - -Q: Can someone write a statement on purpose & scope of Kubeadm? - -To install a minimum viable, best-practice cluster for kubernetes. You have to install your own CNI provider. Kubeadm isn't to endorse any providers at any level of the stack. - -Joe: sub-goal (not required for GA), would be to break out components so that you can just install specific things. -Would also like documentation for what kubeadm does under the covers. - -Josh: requested documentation on "how do I modify my kubeadm install". Feels this is needed for GA. Another attendee felt the same thing. - -One of the other goals is to be a building block for higher-level installers. Talking to Kubespray people, etc. Enabling webhooks used as example. - -There was some additional discussion of various things people might want. One user wanted UI integration with Dashboard. The team says they want to keep the scope really narrow in order to be successful. UI would be a different project. GKE team may be working on some combination of Kubeadm + Cluster API. Amazon is not using Kubeadm, but Docker is. Docker for Mac and Windows will ship with embedded kubernetes in beta later this week. - -Kubeadm dilemma: we want humans to be able to run kubeadm and for it to be a good experience, and for automation to be able to run it. I don't think that can be the same tool. They've been targeting Kubeadm at people, we might want to make a slightly different UI for machines. Josh says that automating it works pretty well, it's just that error output is annoying to capture. - -HA definition: -* etcd should be in a quorum HA standard (3+ nodes) -* more than one master -* all core components: apiserver, scheduler, kcm, need to be on each master -* have to be able to add a master -* upgrades - -Or: we want to be able to survive a loss of one host/node, including a master node. This is different, if we want to survive the loss of any one master, we only need two then. Argument ensued. Also, what about recovery or replacement case? A new master needs to be able to join (manual command). - -What about HA upgrades? Are we going to support going from one master to three? Yes, we have to support that. - -Revised 4 requirements: -* 3+ etcd replicas -* all master components running in each master -* all TLS secured -* Upgrades for HA clusters - -Everyone says that we want a production environment, but it's hard to define what "production grade" means. We need to stop saying that. Over time, what matters is, "is it maintained". If it's still being worked on, over time it'll get better and better. - -CoreOS guy: trying to do self-hosted etcd. There's a lot of unexpected fragile moments. Just HA etcd isn't well tested upstream, there's not enough E2E tests. Self-hosting makes this worse. The etcd operator needs work. There needs to be a lot of work by various teams. Self-hosted control planes work really well, they host all of their customers that way. It's etcd that's special. - -There's some problems with how Kubernetes uses HA Etcd in general. Even if the etcd operator was perfect, and it worked, we couldn't necessarily convince people to use it. - -Should Kubeadm focus on stable installs, or should it focus on the most cutting-edge features? To date, it's been focused on the edge, but going to GA means slowing down. Does this mean that someone else will need to be forward-looking? Or do we do feature flags? - -SIG-Cluster-Lifecycle should also document recommendations on things like "how much memory do I need." But these requirements change all the time. We need more data, and testing by sig-scalability. - -For self-hosting, the single-master situation is different from multi-master. We can't require HA. Do we need to support non-self-hosted? We can't test all the paths, there's a cost of maintaining it. One case for non-self-hosted is security, in order to prevent subversion of nodes. - -Also, we need to support CA-signed Kubelet certs, but that's mostly done. - -So, is HA a necessity for GA? There are a bunch of automation things that already work really well. Maybe we should leave that to external controllers (like Kops etc) to use Kubeadm as a primitive. Now we're providing documentation for how you can provide HA by setting things up. But how would kubeadm upgrade work, then? diff --git a/community/K8sYoutubeCollaboration.md b/community/K8sYoutubeCollaboration.md deleted file mode 100644 index d46c21a2..00000000 --- a/community/K8sYoutubeCollaboration.md +++ /dev/null @@ -1,39 +0,0 @@ - -### Kubernetes Youtube Channel Collaboration -### - -#### Meeting Playlists -#### -The [Kubernetes Youtube Channel](https://www.youtube.com/channel/UCZ2bu0qutTOM0tHYa_jkIwg) has separate playlists for each SIG’s meeting recordings, as well as recordings for other meetings (i.e. Cloud Native, Kubernetes Community meetings). - -To better serve the community, we have setup [collaboration](https://support.google.com/youtube/answer/6109639) on these playlists, so that anyone with the appropriate link to the particular playlist can upload videos *to that particular playlist* (links & playlists are 1:1). - -Each SIG playlist’s link will be shared with the SIG’s leadership, and other playlists' links (i.e. Cloud Native) will be shared with the appropriate point(s) of contact. The SIG playlist links will be sent to the official SIG lead Google Groups. - -#### Uploading Guidelines for Collaborators -#### -Collaboration should simplify things for everyone, but with privilege comes responsibility :). We assume all playlist collaborators in the community will use things fairly and appropriately, subject to the guidelines below: - -1. Once collaboration is setup for each meeting recording playlist, the upload responsibility will fall on the SIG leaders or other appropriate point(s) of contact. Community managers (Sarah and Cameron) *will only be escalation for issues with those playlists* - -2. Please post only related content (mostly meeting recordings) in the appropriate playlists - - Posting of any exceedingly inappropriate content (i.e. NSFW content) will result in ***immediate*** suspension of privileges - -3. Please ensure all videos have the same naming format, which is: - - Kubernetes [Name of Playlist’s Group] YYYYMMDD - - i.e. Kubernetes SIG Service Catalog 20161129 - -4. All playlists need to be organized chronologically for ease of use, which is most easily done by selected “date added, newest” as the “Ordering” option in the playlist settings - -5. Please do not remove any already-published content from the playlists without checking with the community managers - -6. For any small issues that arise (i.e. improper naming / ordering), you may be asked by the community managers to attempt to resolve the issue yourselves - -7. Any egregious or habitual violation* of the above rules will result in suspension of collaboration privileges for the particular individual, or for the entire playlist if the individual can’t be identified - - If an individual is suspended, the playlist link will be remade and the new link will be shared with the non-offending individuals - - If *playlist* collaboration is suspended, uploading by community managers to the playlist of interest will ***not*** be a priority, and will likely occur on a delayed basis - - *Note that "habitual violation" means "more than 3 issues per quarter" - -Your community managers are happy to help with any questions that you may have and will do their best to help if anything goes wrong. Please get in touch via sarahnovotny *at* google *dot* com and jorge *at* heptio *dot* com - - diff --git a/community/elections/2017/BALLOTS.csv b/community/elections/2017/BALLOTS.csv deleted file mode 100644 index 9c67b4c1..00000000 --- a/community/elections/2017/BALLOTS.csv +++ /dev/null @@ -1,310 +0,0 @@ -Timothy St. Clair,Ilya Dmitrichenko,Caleb Miles,Doug Davis,Phillip Whitrock,Kris Nova,Derek Carr,Aaron Crickenberger,Jaice Singer DuMars,Michelle Noorali,Ihor Dvoretskyi,Alex Pollitt,Michael Rubin,Quinton Hoole,Rob Hirschfeld,Aaron Schlesinger,Sebastien Goasguen,Matt Farina,Adnan Abdulhussein,Justin Santa Barbara -20,20,10,20,2,20,15,1,1,2,20,20,2,20,20,20,20,15,20,10 -4,20,20,20,6,20,2,20,20,20,20,5,20,1,20,20,20,20,20,3 -7,16,11,11,11,2,10,5,1,2,7,No opinion,15,5,17,11,9,No opinion,No opinion,2 -20,1,20,20,20,20,20,20,20,20,2,20,20,20,20,20,20,20,20,20 -5,No opinion,8,No opinion,3,No opinion,1,7,No opinion,4,No opinion,No opinion,2,6,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -3,20,5,6,7,2,7,7,7,7,7,1,4,16,18,7,14,19,7,17 -1,20,20,20,20,2,20,20,20,3,20,20,20,20,20,20,4,20,20,20 -4,1,20,20,20,20,20,20,20,3,20,20,20,20,20,20,20,20,2,20 -8,13,16,3,2,7,19,15,6,12,5,18,1,20,11,17,4,9,14,10 -20,20,20,20,20,20,1,20,20,20,20,20,20,20,20,20,20,20,20,20 -6,20,8,20,3,13,1,7,12,2,20,9,4,5,20,20,10,20,11,20 -20,20,3,20,9,1,4,7,2,5,20,20,9,9,20,6,20,20,20,20 -20,20,20,20,20,20,1,20,20,20,20,20,20,20,20,20,20,20,20,20 -2,3,8,20,20,5,1,20,20,6,20,20,20,20,7,20,20,9,20,4 -2,14,8,20,3,9,1,7,13,5,18,10,6,4,19,16,11,15,12,17 -20,20,20,6,20,2,20,4,3,1,20,20,20,5,20,20,20,20,20,20 -6,20,8,20,3,20,1,7,20,2,20,9,4,5,20,20,10,20,20,20 -13,No opinion,7,No opinion,1,11,12,5,10,4,6,No opinion,No opinion,2,No opinion,No opinion,8,No opinion,No opinion,3 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -4,20,8,5,7,6,14,14,3,14,14,1,2,17,15,9,18,14,19,16 -2,8,19,20,4,7,1,10,16,9,5,11,3,6,14,15,13,18,17,12 -5,18,16,11,6,1,12,20,17,4,9,8,7,19,13,14,2,10,15,3 -7,3,12,1,5,19,9,16,18,13,2,15,20,10,6,17,8,11,14,4 -1,14,11,12,7,2,3,6,5,4,17,10,9,16,19,No opinion,8,No opinion,15,20 -20,18,11,2,5,17,9,10,7,8,4,14,19,12,16,15,1,3,6,13 -3,20,7,20,2,20,20,10,9,4,6,20,1,20,20,20,12,8,5,11 -2,20,20,20,20,20,1,4,20,20,6,20,5,3,20,20,20,20,20,20 -2,18,5,12,8,6,1,7,16,9,14,15,3,4,20,13,10,17,19,11 -5,20,20,20,3,1,16,20,20,1,20,20,4,6,20,20,20,20,20,7 -20,11,2,20,1,12,5,11,2,9,6,20,1,20,8,11,9,12,11,6 -2,7,2,1,20,20,5,20,20,20,6,20,20,3,20,20,20,20,20,4 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -20,20,20,20,20,20,2,20,1,20,20,20,20,20,20,20,20,20,20,20 -7,12,8,17,3,11,1,6,10,4,18,15,5,2,20,19,13,14,9,16 -12,1,2,8,17,4,9,3,19,10,14,13,18,11,5,15,7,6,16,20 -7,18,20,4,3,14,1,9,12,2,15,8,5,6,19,17,10,16,11,13 -8,18,15,14,1,10,17,12,3,20,11,20,1,16,20,19,2,20,9,13 -6,20,8,20,7,6,3,4,8,2,20,20,1,9,5,20,20,20,20,4 -2,20,20,20,1,20,20,20,20,20,6,20,3,20,20,20,5,20,20,4 -3,20,20,20,2,20,20,20,20,20,20,20,1,20,20,20,20,20,20,20 -4,10,8,20,5,20,1,3,20,20,6,20,2,11,20,9,20,20,20,7 -20,20,1,20,7,3,20,20,20,2,20,4,6,20,5,20,20,20,20,20 -1,5,13,16,10,20,9,11,12,19,14,17,15,2,18,4,7,3,8,6 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -20,20,20,20,20,1,20,20,20,20,20,20,20,20,20,20,20,20,20,20 -20,20,1,20,3,20,20,6,5,2,20,8,4,7,20,20,20,20,20,9 -2,20,9,20,1,20,2,9,2,1,9,20,7,7,20,20,20,20,20,2 -20,20,2,20,20,20,20,5,20,1,3,20,20,20,6,20,20,20,20,4 -2,20,4,20,4,20,1,20,20,3,20,20,20,20,20,20,20,20,20,20 -2,20,20,20,20,20,1,20,19,3,20,20,20,20,20,20,20,20,20,20 -6,9,No opinion,No opinion,No opinion,5,No opinion,No opinion,4,1,2,No opinion,No opinion,No opinion,3,No opinion,8,No opinion,No opinion,7 -19,9,4,20,1,16,5,7,17,18,3,6,2,10,13,15,11,8,12,14 -8,16,18,12,13,6,15,10,4,19,7,3,9,2,5,11,1,14,17,20 -6,14,8,20,4,13,1,7,12,3,18,9,5,2,19,16,10,15,11,17 -20,20,20,20,2,20,4,20,20,20,20,20,1,20,20,20,20,20,20,4 -14,No opinion,3,13,2,12,No opinion,4,1,6,9,No opinion,11,5,10,8,7,No opinion,No opinion,16 -3,No opinion,No opinion,No opinion,No opinion,2,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -1,18,8,10,9,11,4,5,6,3,17,14,12,2,20,13,16,19,15,7 -No opinion,3,No opinion,No opinion,No opinion,20,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,No opinion,No opinion,1,2,5,No opinion,No opinion -13,13,3,18,1,14,9,5,6,10,8,19,2,20,13,15,4,17,11,7 -No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,1 -7,18,11,14,1,9,8,12,5,2,20,4,10,19,17,6,3,13,16,15 -1,4,15,17,15,6,20,15,16,2,5,15,15,3,7,18,15,19,15,15 -20,20,20,20,20,2,20,20,20,5,20,4,3,1,20,20,20,6,20,20 -2,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,6,No opinion,4,No opinion,7,8,No opinion,3,9,No opinion,5 -20,No opinion,2,3,1,20,2,2,5,20,3,5,1,20,No opinion,20,No opinion,3,No opinion,2 -3,No opinion,No opinion,No opinion,1,5,No opinion,No opinion,No opinion,4,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -2,20,20,20,3,4,1,20,20,5,20,20,20,20,20,6,20,20,20,20 -3,11,8,15,2,12,1,7,10,4,13,9,5,6,13,11,9,11,9,14 -4,9,6,20,3,20,1,5,20,20,20,20,8,20,20,20,20,20,20,1 -8,19,11,19,6,5,10,1,3,7,4,19,2,19,19,12,9,19,19,20 -8,No opinion,16,No opinion,2,13,9,3,1,11,10,No opinion,7,4,5,15,14,12,No opinion,6 -3,7,4,20,10,1,2,20,12,9,20,6,5,11,20,20,20,8,20,20 -20,20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20 -5,20,20,20,2,20,3,20,20,7,4,20,1,6,20,20,20,20,20,20 -13,19,17,20,5,6,7,9,1,2,12,18,14,11,16,8,10,4,3,15 -5,20,19,19,19,2,19,19,7,19,8,1,3,19,6,19,19,19,19,19 -3,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20,2,20,20 -4,20,20,20,5,20,2,1,6,20,20,20,20,20,20,20,20,20,20,3 -6,No opinion,8,No opinion,3,No opinion,1,7,No opinion,2,No opinion,9,4,5,No opinion,No opinion,10,No opinion,No opinion,No opinion -2,5,4,7,18,19,6,11,15,14,16,3,1,20,17,9,8,12,10,13 -20,20,1,20,1,1,20,1,1,1,20,20,20,20,20,20,20,20,20,20 -11,5,No opinion,4,3,No opinion,No opinion,9,No opinion,2,20,10,7,No opinion,No opinion,8,6,No opinion,No opinion,1 -2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,1 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -20,20,1,20,3,20,20,6,5,2,20,8,4,7,20,20,20,20,20,9 -2,No opinion,8,13,3,12,1,9,7,4,No opinion,No opinion,5,6,10,No opinion,No opinion,No opinion,No opinion,11 -6,19,3,19,19,7,9,2,1,19,5,19,7,4,19,10,19,19,19,20 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -2,6,13,20,12,5,19,10,19,9,8,14,6,19,7,19,4,1,3,11 -10,10,8,10,1,10,1,10,1,10,1,1,8,20,10,10,1,10,10,1 -8,14,3,12,6,15,1,9,11,5,20,10,2,7,20,20,20,13,20,4 -6,4,5,13,7,1,17,17,10,3,11,8,17,18,20,9,17,19,12,2 -5,14,7,20,2,13,1,6,12,8,18,9,3,4,19,16,10,15,11,17 -4,18,20,18,1,19,14,17,2,18,13,18,15,18,12,18,16,18,18,3 -2,9,20,20,11,5,8,3,4,6,10,20,20,20,7,12,11,20,20,1 -13,7,11,16,1,20,3,6,5,19,14,9,4,17,15,12,8,10,18,2 -1,20,20,20,20,2,20,20,20,3,20,20,20,6,20,4,20,20,20,5 -4,14,7,20,3,12,1,8,19,2,18,10,6,5,16,17,15,11,9,13 -No opinion,5,2,No opinion,No opinion,4,No opinion,No opinion,2,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion -20,20,20,20,2,20,20,20,20,20,20,20,1,20,20,20,20,20,20,20 -6,10,7,12,5,16,3,13,19,9,8,11,2,1,18,20,15,17,14,4 -6,3,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,7,No opinion,1,5,No opinion,No opinion,No opinion,No opinion,No opinion,4 -20,20,5,20,1,20,5,2,4,20,20,20,3,20,20,20,20,20,20,5 -3,20,8,20,4,20,1,20,20,5,20,20,2,7,20,20,20,20,20,6 -7,5,20,15,4,17,10,1,6,3,9,18,2,13,16,19,11,14,8,12 -4,7,No opinion,No opinion,No opinion,3,No opinion,6,8,2,9,No opinion,No opinion,5,No opinion,No opinion,No opinion,No opinion,10,1 -20,20,20,20,20,1,20,4,20,2,8,5,3,20,20,7,20,6,20,20 -18,16,15,20,5,2,17,19,9,1,3,11,10,12,13,7,4,8,6,14 -2,12,14,15,8,3,7,13,4,1,5,18,16,19,17,6,11,20,9,10 -3,20,4,20,1,20,1,2,2,20,2,20,1,20,20,20,20,20,20,2 -4,17,5,14,18,1,11,8,10,2,3,19,20,7,6,9,16,15,13,12 -5,10,10,20,2,5,3,20,10,5,10,20,1,10,20,20,20,10,20,5 -6,20,8,20,3,20,1,7,20,2,20,9,4,5,20,20,10,20,20,20 -3,20,5,20,9,20,1,7,20,8,20,20,2,20,20,20,20,20,20,4 -7,20,8,20,20,20,3,4,6,20,20,20,1,5,20,20,20,20,20,2 -20,20,20,3,7,4,20,5,2,20,6,20,20,20,20,20,20,20,20,1 -3,20,5,14,10,7,13,1,4,6,12,8,9,20,20,20,11,2,20,20 -11,2,18,20,16,3,10,17,1,7,19,12,15,5,14,4,13,9,6,8 -5,20,7,20,1,20,4,20,20,2,20,20,20,3,20,20,20,20,20,6 -15,No opinion,6,13,1,No opinion,14,3,4,10,7,No opinion,2,12,No opinion,No opinion,7,7,No opinion,5 -15,14,12,8,16,11,1,19,17,20,4,10,3,13,9,5,18,7,6,2 -7,19,10,10,1,20,9,11,16,3,18,6,2,4,8,13,5,15,14,17 -3,5,10,13,2,9,4,20,6,12,15,16,1,14,11,8,18,19,7,17 -3,18,5,20,12,6,1,10,13,2,14,8,7,4,16,17,9,19,11,15 -20,20,4,20,2,20,8,7,3,20,6,20,1,20,20,20,20,20,20,5 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,2 -8,12,7,No opinion,4,11,1,13,3,10,6,No opinion,2,9,No opinion,14,No opinion,No opinion,No opinion,5 -2,20,8,20,11,20,1,20,9,7,20,20,6,5,12,4,10,20,20,3 -20,19,8,17,1,10,17,17,17,10,11,17,2,7,17,3,7,10,18,7 -20,20,20,20,1,20,5,4,20,20,20,20,3,6,20,20,20,20,20,2 -4,7,6,20,11,3,15,10,19,1,13,8,14,16,12,5,17,2,9,18 -19,20,20,20,20,20,20,20,20,20,1,2,20,20,18,20,20,20,20,20 -No opinion,No opinion,19,No opinion,12,18,15,20,11,10,13,No opinion,16,No opinion,14,17,8,No opinion,No opinion,9 -4,14,7,20,3,12,1,18,13,2,10,8,6,5,19,17,9,15,11,16 -2,20,20,20,20,20,1,20,4,20,20,20,3,20,20,20,20,20,20,5 -4,No opinion,3,12,6,15,13,11,10,13,10,20,2,18,5,10,1,10,10,14 -1,2,20,20,20,2,20,20,20,20,20,20,20,3,20,20,20,20,20,20 -20,16,17,19,8,18,6,2,4,5,3,12,9,10,15,14,13,1,7,11 -6,No opinion,11,No opinion,13,1,4,No opinion,3,2,5,No opinion,8,No opinion,No opinion,10,12,No opinion,9,7 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -17,20,18,20,2,20,5,18,18,10,4,20,1,3,20,18,7,20,20,6 -7,4,7,7,7,2,7,7,7,7,3,7,6,5,7,7,7,7,7,1 -6,9,9,4,6,1,7,8,4,2,10,7,5,5,9,10,8,5,3,6 -4,No opinion,No opinion,1,3,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,5,No opinion,No opinion,No opinion,No opinion -6,11,8,20,3,10,1,7,9,2,14,13,4,5,15,18,16,17,12,19 -11,No opinion,No opinion,No opinion,9,1,No opinion,No opinion,No opinion,7,6,8,5,10,4,No opinion,3,No opinion,12,2 -20,20,4,20,1,20,20,20,20,20,20,20,1,6,20,20,20,20,5,20 -14,1,13,12,7,20,6,8,1,15,16,4,3,5,2,10,19,17,11,9 -5,6,No opinion,No opinion,No opinion,1,No opinion,No opinion,4,2,5,5,No opinion,No opinion,4,3,No opinion,No opinion,No opinion,3 -19,6,4,20,8,13,7,11,10,9,14,2,1,20,3,17,12,15,16,5 -11,6,9,20,4,2,3,12,10,8,5,13,20,20,20,20,20,20,7,1 -3,20,4,20,7,4,20,1,20,20,4,20,20,20,20,8,20,2,20,20 -14,1,5,No opinion,6,3,11,2,7,9,10,No opinion,15,8,12,No opinion,4,16,13,No opinion -6,20,20,20,20,2,20,17,7,3,20,20,20,18,20,20,20,18,20,18 -5,10,9,17,6,20,15,2,1,4,11,15,8,12,18,3,8,15,16,19 -3,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,8,4,No opinion,No opinion,2,6,No opinion,No opinion,7,No opinion,No opinion,5 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -7,20,9,20,2,5,1,8,10,3,20,20,6,4,20,20,20,20,20,20 -6,14,8,20,3,12,1,7,13,2,19,9,4,5,17,18,10,15,11,16 -2,No opinion,No opinion,No opinion,No opinion,5,3,No opinion,7,6,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,No opinion,No opinion,1 -11,No opinion,10,No opinion,4,No opinion,1,2,8,5,13,No opinion,6,7,No opinion,No opinion,9,3,12,20 -12,14,1,20,7,15,4,3,9,10,11,5,6,18,19,16,2,8,17,13 -2,16,13,19,7,6,11,17,9,5,18,20,1,12,10,15,3,14,4,8 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -5,No opinion,No opinion,3,No opinion,2,1,No opinion,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -1,6,18,16,4,3,2,17,5,No opinion,19,No opinion,No opinion,6,No opinion,No opinion,No opinion,No opinion,No opinion,20 -20,11,7,6,1,16,3,12,5,15,2,18,1,4,19,17,13,14,10,8 -20,20,20,20,2,20,20,20,20,20,20,20,1,20,20,20,20,20,20,3 -9,19,3,2,6,16,10,1,5,No opinion,15,8,14,17,13,12,4,7,11,18 -2,20,20,19,20,5,1,19,19,3,4,20,20,20,20,20,20,19,20,19 -6,14,8,14,3,12,1,7,12,2,14,9,4,5,14,14,9,14,9,14 -2,20,1,20,3,20,20,20,20,20,20,20,20,4,20,20,20,20,20,20 -2,3,3,3,3,3,3,3,3,3,3,3,1,3,3,3,3,3,3,3 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -8,10,18,9,1,20,7,5,13,6,4,11,3,19,14,15,12,16,17,2 -2,8,5,18,1,No opinion,2,19,9,19,No opinion,5,6,19,18,19,20,No opinion,19,1 -3,20,8,20,20,5,20,1,4,6,20,7,20,20,20,20,20,2,20,20 -3,14,7,20,6,13,2,8,12,4,20,10,5,1,20,16,9,15,11,17 -6,20,10,20,3,20,1,10,20,2,20,15,4,5,20,20,15,20,15,20 -10,15,2,11,13,14,1,17,19,18,7,19,6,12,20,9,16,5,4,3 -7,8,10,No opinion,No opinion,11,2,No opinion,5,1,4,No opinion,9,6,No opinion,No opinion,No opinion,No opinion,No opinion,3 -20,20,20,6,2,4,20,20,20,5,20,20,1,20,20,3,20,20,20,20 -5,3,9,4,15,1,17,18,12,2,6,20,19,11,16,7,14,13,8,10 -4,No opinion,1,No opinion,No opinion,2,No opinion,No opinion,No opinion,5,No opinion,3,No opinion,6,No opinion,No opinion,No opinion,No opinion,No opinion,7 -1,11,4,15,5,6,8,9,2,7,20,17,3,10,13,12,19,14,16,18 -5,3,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,2,No opinion,6,No opinion,No opinion,No opinion -2,4,20,20,20,20,1,20,20,20,20,5,20,20,20,20,3,20,20,20 -4,20,5,6,12,7,8,11,3,9,14,1,2,18,10,13,17,16,15,19 -20,20,20,20,20,20,2,20,20,20,20,20,20,20,20,20,20,20,20,1 -No opinion,No opinion,No opinion,1,No opinion,No opinion,2,No opinion,No opinion,7,No opinion,No opinion,No opinion,6,No opinion,No opinion,No opinion,3,5,4 -5,20,20,20,20,20,20,20,1,2,20,20,3,20,20,20,20,20,20,4 -11,13,18,3,10,15,6,8,17,4,14,9,7,12,19,20,1,2,5,16 -1,19,19,19,19,4,20,5,2,19,19,19,3,19,19,19,19,19,19,19 -20,19,19,19,19,19,18,17,19,17,19,19,19,19,19,19,19,18,19,19 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -5,18,7,20,3,12,1,8,13,2,18,10,4,6,19,18,11,18,9,18 -2,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -4,5,20,20,20,1,20,20,20,3,20,2,20,20,20,20,20,20,20,20 -3,12,6,17,1,15,13,14,9,5,19,7,2,20,10,18,11,8,16,4 -6,18,8,20,3,18,1,7,18,2,18,18,4,5,18,18,18,18,18,18 -1,No opinion,3,No opinion,No opinion,2,4,No opinion,No opinion,No opinion,No opinion,7,No opinion,5,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -20,20,20,20,20,1,20,20,4,2,20,3,20,20,20,20,20,20,20,20 -10,3,4,No opinion,No opinion,12,No opinion,No opinion,No opinion,8,1,7,No opinion,No opinion,9,No opinion,1,5,6,11 -20,8,12,19,7,18,14,5,1,3,9,16,18,15,17,6,11,2,4,13 -5,15,6,20,12,10,16,7,18,2,1,14,19,17,8,11,13,4,3,9 -10,19,16,3,2,14,5,20,12,17,18,4,1,7,9,8,6,15,13,11 -6,20,5,20,4,20,20,1,8,7,20,20,3,20,20,20,9,2,20,20 -12,16,7,20,1,6,9,5,8,4,14,3,2,18,17,11,13,15,19,10 -8,20,20,20,1,20,3,20,20,4,20,20,2,6,20,7,5,20,10,9 -6,No opinion,No opinion,No opinion,2,No opinion,No opinion,20,No opinion,3,19,No opinion,1,18,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -No opinion,1,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,6,5,No opinion,No opinion,4,8,No opinion,7,No opinion,No opinion,2 -4,8,18,15,5,6,1,12,13,14,16,19,3,10,17,11,7,20,2,9 -6,12,8,18,4,13,1,5,17,2,16,9,3,7,19,14,11,20,10,15 -5,20,8,20,3,12,1,7,12,2,20,9,4,6,20,20,9,20,9,20 -10,11,20,14,19,2,18,16,4,1,7,6,17,13,5,3,8,12,9,15 -No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -8,14,6,17,13,4,20,16,18,1,19,12,5,2,15,3,7,9,11,10 -1,20,8,20,7,16,13,20,4,5,6,14,2,10,11,3,9,12,20,15 -19,16,17,19,8,3,4,6,5,3,2,11,1,19,19,7,10,15,12,9 -3,20,20,20,2,20,20,20,20,20,4,7,1,6,5,20,20,20,20,20 -9,11,13,15,2,1,7,20,12,3,6,14,8,4,19,5,16,18,10,17 -6,20,8,20,3,9,1,10,20,2,20,7,4,5,20,20,20,20,20,20 -1,20,6,20,5,4,20,20,2,3,20,20,20,7,9,20,20,20,8,20 -19,19,4,19,2,19,19,5,3,19,19,19,1,19,7,19,19,19,19,6 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -20,1,20,20,20,20,4,20,20,20,1,20,20,20,20,20,1,20,20,20 -9,No opinion,6,13,3,18,1,16,8,2,16,14,10,7,19,18,17,11,20,4 -No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,3,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,20 -4,20,3,20,5,20,20,20,20,20,20,6,20,20,2,20,20,20,20,1 -20,20,20,20,1,20,20,20,4,20,20,20,20,3,20,20,20,20,20,2 -6,8,1,No opinion,13,9,7,3,2,5,11,10,No opinion,14,4,No opinion,20,No opinion,No opinion,No opinion -10,7,12,18,17,8,15,4,2,5,6,3,9,19,1,16,11,15,15,20 -4,2,9,20,10,3,20,20,6,7,20,20,20,8,20,5,20,20,20,1 -5,19,6,20,9,1,No opinion,20,11,2,3,4,18,No opinion,20,12,10,7,20,8 -No opinion,No opinion,1,No opinion,No opinion,4,No opinion,No opinion,3,5,No opinion,No opinion,No opinion,2,6,7,No opinion,No opinion,No opinion,No opinion -5,20,5,20,3,20,4,20,2,20,20,20,1,6,20,20,20,20,20,20 -6,20,1,7,20,3,8,20,20,5,2,20,20,4,9,20,20,20,20,20 -12,11,1,14,2,10,20,3,4,7,9,13,6,8,15,19,16,18,17,5 -5,20,20,20,2,20,6,20,4,20,15,20,1,4,20,20,20,20,20,3 -8,15,10,19,7,6,1,2,3,12,17,5,4,9,18,20,14,16,11,13 -6,2,20,20,20,5,20,20,20,1,3,4,20,8,20,20,9,20,7,20 -5,8,6,9,2,18,4,20,15,16,20,7,1,12,11,17,10,19,13,3 -5,12,8,11,3,4,2,12,12,1,10,12,12,6,12,12,7,12,11,7 -2,9,12,20,5,20,4,11,8,6,20,20,3,7,10,20,20,20,20,1 -20,20,20,20,1,20,20,20,20,20,20,20,2,20,20,20,20,20,20,20 -5,20,6,20,3,20,2,20,20,20,8,20,1,7,20,20,20,20,20,4 -1,3,No opinion,No opinion,No opinion,1,3,No opinion,3,1,2,No opinion,No opinion,No opinion,2,No opinion,2,No opinion,No opinion,No opinion -1,20,15,11,5,4,13,7,8,6,16,2,3,9,10,12,18,14,17,17 -4,2,1,1,2,No opinion,2,1,2,1,1,No opinion,2,20,No opinion,No opinion,5,2,3,1 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -9,5,18,18,10,19,11,18,8,6,18,18,1,4,3,18,2,20,18,7 -5,9,6,9,2,8,1,6,8,3,9,7,4,4,9,9,7,9,7,9 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -19,19,5,19,1,6,19,19,3,19,19,19,2,20,19,19,19,19,19,4 -No opinion,No opinion,1,No opinion,No opinion,7,No opinion,No opinion,No opinion,2,6,No opinion,No opinion,No opinion,No opinion,4,No opinion,3,5,No opinion -6,14,4,11,5,16,2,1,8,3,17,20,18,19,15,13,10,12,9,7 -4,5,20,20,2,20,1,20,20,20,20,20,3,20,20,20,20,20,20,20 -10,20,20,20,20,1,20,20,20,2,20,20,20,20,20,20,20,20,20,10 -9,19,19,19,4,20,11,19,19,5,6,7,10,19,12,2,19,1,5,3 -3,No opinion,4,No opinion,3,No opinion,No opinion,2,1,2,5,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -1,No opinion,2,No opinion,1,3,1,1,2,3,3,2,1,2,2,No opinion,No opinion,No opinion,No opinion,1 -2,20,20,20,20,20,20,20,20,20,20,20,3,4,20,20,20,20,20,1 -20,17,3,20,1,20,5,17,14,4,20,17,2,20,20,18,19,20,19,17 -6,12,8,20,3,7,1,5,9,2,13,16,10,4,20,15,11,14,17,20 -20,20,20,20,20,20,10,20,20,20,20,20,20,1,20,20,20,20,20,10 -18,11,3,16,4,7,1,9,6,10,2,5,19,20,17,15,13,12,8,14 -3,9,7,15,11,20,8,1,19,13,4,14,12,6,10,16,18,2,17,5 -2,20,3,2,2,20,20,20,20,20,1,1,2,2,3,20,20,20,20,20 -8,9,3,No opinion,1,10,4,7,10,10,6,No opinion,2,14,No opinion,10,No opinion,No opinion,No opinion,5 -20,1,11,20,15,3,6,8,5,7,15,9,20,4,15,2,13,10,16,12 -3,20,6,20,4,9,2,20,20,5,20,8,20,20,20,10,20,20,20,7 -6,20,20,20,2,20,3,20,7,7,20,5,4,20,20,8,20,20,7,1 -20,20,20,6,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,5 -3,13,8,20,2,16,1,6,12,4,18,9,7,5,19,15,10,14,11,17 -3,20,6,20,1,20,20,20,5,20,20,20,2,4,20,20,20,20,20,20 -6,19,19,1,19,4,19,5,19,2,19,3,19,19,20,19,19,19,19,19 -2,3,6,No opinion,No opinion,8,No opinion,1,7,9,No opinion,No opinion,No opinion,No opinion,No opinion,5,4,No opinion,No opinion,20 -3,4,No opinion,No opinion,8,9,No opinion,No opinion,11,5,10,6,15,1,7,No opinion,2,12,No opinion,13 -20,20,20,20,20,2,20,1,2,2,20,20,20,3,20,20,3,20,20,2 -5,10,3,12,6,14,9,1,7,4,13,17,19,11,15,20,8,2,16,18 -5,11,8,20,3,14,1,7,13,2,18,10,4,6,19,16,9,15,12,17 -12,8,14,No opinion,4,10,No opinion,9,7,2,11,No opinion,No opinion,No opinion,No opinion,6,5,1,3,13 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -6,20,20,20,3,20,1,20,20,2,20,20,4,5,20,20,20,20,20,20 -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -6,20,8,20,2,20,1,5,12,3,19,20,3,6,20,18,20,20,20,17 -4,1,20,20,20,1,20,20,5,2,4,3,20,3,20,20,20,20,20,3 -3,4,No opinion,No opinion,1,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,3 -20,10,20,10,5,20,6,10,20,4,10,3,1,20,10,20,10,10,10,2 -10,20,1,20,1,2,10,1,15,15,4,4,1,20,10,20,15,15,20,15 -20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 -2,5,19,7,3,9,1,6,10,11,5,5,5,12,20,10,17,4,8,9 -6,9,3,17,13,17,13,1,17,3,9,3,17,6,9,13,9,1,13,6 -2,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 -8,2,4,10,6,18,20,3,9,16,17,5,14,7,12,13,1,11,15,19 -5,7,20,20,2,20,3,5,20,20,20,20,1,20,20,20,20,20,20,3 -No opinion,No opinion,20,No opinion,No opinion,No opinion,20,No opinion,20,No opinion,No opinion,No opinion,20,1,No opinion,No opinion,No opinion,No opinion,No opinion,20 -20,14,13,16,1,12,3,17,8,4,19,10,2,18,18,11,7,15,6,5 -6,20,4,5,11,7,8,9,3,15,10,1,2,16,12,13,19,17,14,18 -1,No opinion,No opinion,No opinion,No opinion,2,4,5,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -4,No opinion,No opinion,No opinion,3,No opinion,1,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion -19,17,19,6,20,19,20,1,19,19,16,17,20,3,17,2,17,18,17,16 -20,7,12,16,8,2,20,4,5,10,16,16,3,6,20,16,9,11,16,1 -3,4,5,20,20,20,2,20,20,3,20,20,20,1,20,20,20,3,2,4 -13,7,5,20,1,9,3,4,2,6,8,5,1,11,10,10,20,20,20,12 -7,20,20,1,20,5,4,8,20,20,6,7,2,10,9,20,20,20,20,3 diff --git a/community/elections/2017/README.md b/community/elections/2017/README.md deleted file mode 100644 index 0d17f68c..00000000 --- a/community/elections/2017/README.md +++ /dev/null @@ -1,77 +0,0 @@ -# 2017 VOTERS GUIDE - KUBERNETES STEERING COMMITTEE ELECTION - -This election has been completed. - -[Results](RESULTS.md) - -# PURPOSE -The initial role of the steering committee is to instantiate the formal governance process for Kubernetes. In addition to defining the initial governance process, the [bootstrap committee](https://groups.google.com/forum/#!msg/kubernetes-dev/4e8WOnMvZC0/57GYmJKfDAAJ) strongly believes that it is important to provide a means for iterating the processes defined by the steering committee. We do not believe that we will get it right the first time, or possibly ever, and won’t even complete the governance development in a single shot. The role of the steering committee is to be a living, responsive body that can refactor and reform as necessary to adapt to a changing project and community. - -# VOTING -This election will shape the future of Kubernetes as a project and community. You will be voting on six (6) seats up for election, three with a two year term and three with an initial one year term. The motivation for these different terms is to set up an initial stagger so that the entire committee isn’t replaced every election cycle. After this first election, every elected community member will serve a two year term. - -The candidates you are voting on will be meeting regularly to strategically grow the project with contributors in mind. Most of the technical decisions, architecture planning, and the like come out of SIGs and other working groups. Some examples of responsibilities to consider as you are voting: -* Define, evolve, and defend the vision, values, mission, and scope of the project - to establish and maintain the soul of Kubernetes -* Charter and refine policy for defining new community groups (including Special Interest Groups, Working Groups, and Committees), and establish transparency and accountability policies for such groups. -* Define, evolve, and defend a Code of Conduct, which must include a neutral, unbiased process for resolving conflict - -Full scope of responsibilities, goals, and/or future election timelines, see [steering committee charter](https://github.com/kubernetes/steering/blob/master/charter.md). - -For more context, please see the [current issues](https://github.com/kubernetes/steering/blob/master/backlog.md) that need to be resolved or a previous governance [meeting video](https://www.youtube.com/watch?v=ltRKXLl0RaE&list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ&index=23) which lead to this whole process. - -## PROCESS -Elections will be held using time-limited [Condorcet](https://en.wikipedia.org/wiki/Condorcet_method) ranking on [CIVS](http://civs.cs.cornell.edu/) using the [Schulze method](https://en.wikipedia.org/wiki/Schulze_method). The top vote getters, modulo the corporate diversity requirement of no more than 1/3 of the committee from a single company, will be elected to the respective positions, with the top 3 filling the 2 year term seats, and the next 3 filling the 1 year term seats. - -You will be ranking your choices 1-20 with an option for no opinion. In the event of a tie, a coin will be flipped. - -The election will open for voting on September 19, 2017 at 09:00am PDT and end two weeks after on October 3, 2017 at 06:00pm PDT. You will receive an email to the address on file at the start of the election from Jorge Castro (jorge@heptio), Community Manager, please whitelist if necessary. Detailed voting instructions will be addressed in email and the CIVS polling page. - -## ELIGIBILITY -Members of Standing are defined by the union of: -* SIG leads -* Approvers and reviewers in any Kubernetes owned repositories -* Anyone with write access to a Kubernetes owned repository -* Active members of our community -If you believe you are a Member of Standing, please fill out [this form](https://docs.google.com/forms/d/e/1FAIpQLSeoeNSl9ufZ_jpp7OHgvtWm-GRFV6WUwTIqZ9W25eMd3xyyvg/viewform) before September 13, 2017. - -## DECISION -The newly elected body will be announced in the weekly Kubernetes Community Meeting on October 5, 2017 at 10:00am US Pacific Time. [Please join us](https://groups.google.com/forum/#!forum/kubernetes-community-video-chat). - -Following the meeting, the raw voting results and winners will be published on the [Kubernetes Blog](http://blog.kubernetes.io/). - -For more information, definitions, and/or detailed election process, see full [steering committee charter](https://github.com/kubernetes/steering/blob/master/charter.md). - -# NOMINEES -Don’t know someone on this list? We asked the nominees to provide a <300 word bio about their k8s experience that we'll link to their name in this table. - -Name | Organization/Company | GitHub ---- | --- | --- -[Aaron Crickenberger](aaroncrickenberger_bio.md) | Samsung SDS | [@spiffxp](https://github.com/spiffxp) -[Aaron Schlesinger](aaronschlesinger_bio.md) | Microsoft | [@arschles](https://github.com/arschles) -[Adnan Abdulhussein](adnanabdulhussein_bio.md) | Bitnami | [@prydonius](https://github.com/prydonius) -[Alex Pollitt](alexpollitt_bio.md) | Tigera | [@lxpollitt](https://github.com/lxpollitt) -[Caleb Miles](calebamiles_bio.md) | CoreOS | [@calebamiles](https://github.com/calebamiles) -[Derek Carr](derekcarr_bio.md) | Red Hat | [@derekwaynecarr](https://github.com/derekwaynecarr) -[Doug Davis](dougdavis_bio.md) | IBM | [@duglin](https://github.com/duglin) -[Ihor Dvoretskyi](idvoretskyi_bio.md) | CNCF | [@idvoretskyi](https://github.com/idvoretskyi) -[Ilya Dmitrichenko](errordeveloper_bio.md) | Weave | [@errordeveloper](https://github.com/errordeveloper) -[Jaice Singer DuMars](jaicesingerdumars_bio.md) | Microsoft | [@jdumars](https://github.com/jdumars) -[Justin Santa Barbara](vote_for_justinsb.md) | Independent | [@justinsb](https://github.com/justinsb) -[Kris Nova](kris-nova_bio.md) | Microsoft | [@kris-nova](https://github.com/kris-nova) -[Matt Farina](mattfarina_bio.md) | Samsung SDS | [@mattfarina](https://github.com/mattfarina) -[Michael Rubin](michaelrubin_bio.md) | Google | [@matchstick](https://github.com/matchstick) -[Michelle Noorali](michellenoorali_bio.md) | Microsoft | [@michelleN](https://github.com/michelleN) -[Phillip Wittrock](pwittrock_bio.md) | Google | [@pwittrock](https://github.com/pwittrock) -[Quinton Hoole](quintonhoole_bio.md) | Huawei | [@quinton-hoole](https://github.com/quinton-hoole) -[Rob Hirschfeld](rhirschfeld_bio.md) | RackN | [@zehicle](https://github.com/zehicle) -[Sebastien Goasguen](sebastiengoasguen_bio.md) | Bitnami | [@sebgoa](http://github.com/sebgoa) -[Timothy St. Clair](timothysc_bio.md) | Heptio | [@timothysc](https://github.com/timothysc) - - -Note:The bootstrap committee members have -recused themselves from any form of electioneering, including -campaigning, nominating, endorsing, or even asking people to run. - -Please direct any questions via email to
-[K8s Slack](http://slack.k8s.io/) - diff --git a/community/elections/2017/RESULTS.md b/community/elections/2017/RESULTS.md deleted file mode 100644 index 008ac2ff..00000000 --- a/community/elections/2017/RESULTS.md +++ /dev/null @@ -1,53 +0,0 @@ -# Results of the 2017 Steering Committee Election - -Number of seats open: 3 (2 year term), 3 (1 year term) - -Number of eligible voters: 392 - -Number of votes cast: 309 - -Turnout: 78.8% - -[Raw ballot data](BALLOTS.csv) - -## Results - -The final ranking, using the "Schulze" Condorcet completion, is as follows: - -1. Derek Carr -2. Michelle Noorali -3. Phillip Wittrock -4. Michael Rubin -5. Timothy St. Clair -6. Quinton Hoole -7. Aaron Crickenberger -8. Caleb Miles -9. Jaice Singer DuMars -10. Kris Nova -11. Justin Santa Barbara -12. Alex Pollitt -13. Sebastien Goasguen -14. Ihor Dvoretskyi -15. Adnan Abdulhussein -16. Ilya Dmitrichenko -17. Matt Farina -18. Aaron Schlesinger -19. Rob Hirschfeld -20. Doug Davis - -According to the limits on company representation, Google would be -over-represented with this result, so Michael Rubin must be excluded. - -## Winners - -The winners of the open seats are as follows: - -Two year term: -1. Derek Carr -2. Michelle Noorali -3. Phillip Wittrock - -One year term: -1. Timothy St. Clair -2. Quinton Hoole -3. Aaron Crickenberger diff --git a/community/elections/2017/aaroncrickenberger_bio.md b/community/elections/2017/aaroncrickenberger_bio.md deleted file mode 100644 index d3773272..00000000 --- a/community/elections/2017/aaroncrickenberger_bio.md +++ /dev/null @@ -1,23 +0,0 @@ -# Aaron Crickenberger - -I can be reached as [@spiffxp](https://github.com/spiffxp) on github, slack, gmail, linkedin, twitter, soundcloud, etc - -## What I've done - -I have been involved in open source projects since 2007, cloud related projects since 2009, and Kubernetes since 2015. - -I co-founded SIG Testing. I actively contribute in SIG Contributor Experience, Release, Scale. If you attend the weekly Kubernetes Community meetings, chances are you've seen me (or at least my beard.) - -I have participated in every Kubernetes release since v1.4. I drafted release notes for [v1.4](https://github.com/kubernetes/kubernetes/pull/33410) and [v1.5](https://github.com/kubernetes/features/pull/140). I am a member of of the [v1.8 release team](https://github.com/kubernetes/features/blob/master/release-1.8/release_team.md). - -I helped found [the kubernetes/community repo](https://github.com/kubernetes/community/pull/3). - -## What I'll do - -[The same thing we do every night Pinky...](https://www.youtube.com/watch?v=XJYmyYzuTa8) - -I will advocate for transparency and accountability in our decision making process. I will strive for simplicity and human-sized solutions to large-scale problems where possible. I will continue to push for community empowerment and ownership of key project responsibilities. Narf. - -## Where I work - -Samsung SDS, as part of the [Cloud Native Computing Team](https://samsung-cnct.github.io) diff --git a/community/elections/2017/aaronschlesinger_bio.md b/community/elections/2017/aaronschlesinger_bio.md deleted file mode 100644 index 84f043ec..00000000 --- a/community/elections/2017/aaronschlesinger_bio.md +++ /dev/null @@ -1,53 +0,0 @@ -# Aaron Schlesinger - -- Github: [arschles](https://github.com/arschles) -- Twitter: [@arschles](https://twitter.com/arschles) - -# About - -I'm a Sr. Software Engineer, Microsoft Azure Containers Group. - -I'm a passionate engineer, teacher and leader with over 10 years software engineering and -architecture experience. - -I believe that Kubernetes will truly succeed when we improve the developer and -user experience. - -# Experience - -I've made contributions to [helm](https://github.com/kubernetes/helm), [helm charts](https://github.com/kubernetes/charts), [minikube](https://github.com/kubernetes/minikube), [service-catalog](https://github.com/kubernetes-incubator/service-catalog) and I am a co-lead of SIG-Service-Catalog. - -Outside of Kubernetes, I've spent over 10 years speaking at conferences, teaching Go & Scala, -building large systems, sitting on standards bodies, and contributing to other open source -projects. - -# Promises - -Here are my promises to the community should I be elected to the committee. - -Above all, I want Kubernetes to be a nice place to work. That means: - -- Engineers can build or improve things easily -- Engineers have clear expectations how & (generally) when they will get feedback on their work -- Engineers get constructive feedback on their work -- Everyone is treated with respect, and can resolve interpersonal problems amicably - -Holistically, most of these points are true most of the time, but Kubernetes is growing so -fast and is so diverse that all of them are not always guaranteed right now. - -I realize no community can achieve everything all the time, but I believe we can do better -together. - -I want to improve the following immediately: - -- Improve user _and_ developer documentation -- Create clearer guidelines on how reviews should happen -- Clarify how to rise as a contributor - -Additionally, I'll contribute best to the committee as a representative of end users -and developers. - -I will keep the same promises in the steering committee as I do in SIG-Service-Catalog: - -- **I will always solicit user and developer experiences before making decisions** -- **I will always tackle user and developer problems before anything else** diff --git a/community/elections/2017/adnanabdulhussein_bio.md b/community/elections/2017/adnanabdulhussein_bio.md deleted file mode 100644 index 81371e5e..00000000 --- a/community/elections/2017/adnanabdulhussein_bio.md +++ /dev/null @@ -1,46 +0,0 @@ -# Adnan Abdulhussein - -- GitHub/Slack/Twitter: @prydonius -- Email: adnan@bitnami.com - -## Background - -I joined the Kubernetes community in 2016, and have contributed in a number of -capacities since: - -- Core contributor of Helm -- Co-leading the Kubernetes Charts project -- Kicked off the Helm incubation process and community docs -- Co-leading SIG Apps -- Regularly speaking and advocating for Kubernetes - -Prior to my involvement in Kubernetes, I have been an active maintainer of -Bitnami's open source container images. My work at Bitnami is heavily focused on -making containers and Kubernetes both accessible and easy to use. - -I am honoured to be amongst the amazing group of people nominated for the -Steering Committee. If elected, my goal will be to help Kubernetes grow into a -rich and diverse community. - -## Where I see myself contributing - -As someone who isn't completely focused on Kubernetes core, I think an important -part of the project is the ecosystem around it. I am deeply interested in being -part of discussions, as part of the Steering Committee, to define the vision of -the project, and to decide what relevant sub-projects should be part of -Kubernetes to continue building a strong ecosystem and brand. This also means -making sure sub-projects have the resources they need (i.e. CI, documentation -websites) to succeed and promote their roles in the overall project. - -The diversity and inclusivity is one of the things that I value the most about -the Kubernetes community. I think it's important that we uphold these values -when defining and practicing a Code of Coduct and refining the contributor -experience. - -Another area of the Steering Commitee I'm interested in is furthering the -transparency and accountability for SIGs. I believe improving the communication -and enabling more knowledge sharing will empower both community and consumers. - -## Where I work - -Bitnami diff --git a/community/elections/2017/alexpollitt_bio.md b/community/elections/2017/alexpollitt_bio.md deleted file mode 100644 index 2dbd3f37..00000000 --- a/community/elections/2017/alexpollitt_bio.md +++ /dev/null @@ -1,27 +0,0 @@ -# Alex Pollitt - -I am excited to have been nominated for the steering committee. I recognize that doing -the role justice will be a demanding and time consuming commitment, but I would like -to do my part to help maintain and foster the growth of this amazing community of -contributors and users. - -For those of you who don’t know me, I am one of the founders of Tigera, the company behind -Calico, and active contributors to flannel, CNI, Kubernetes, and Istio. I’ve been working -with the Kubernetes community since 2014 and have great respect for everyone I’ve had the -chance to get to know along the way. - -Since the early days of the project, when friends used to ask, “which container orchestrator -would you bet on?”, my answer was always Kubernetes – not because of the great design -principles, but because of how the founding team and those already contributing welcomed -others to take part and collaborate with an equal voice to move the project forward. For me, -“Kubernetes” means the people and how they work together, as much as technology. - -One example I experienced was the k8s-sig-net efforts to agree a network policy API. In -other communities, this might have descended into vendors trying to get one up on each -other. Instead there was true collaboration, focusing on technical merit and meeting the needs -of future users. It was awesome to play a part in that process and even though it was just one -small corner of Kubernetes it’s a great illustration of why I love working in this community. - -If elected, I promise to do my utmost to foster and facilitate this kind of diverse, vendor -neutral, merit based collaboration, empower and support contributors to shape the project, -and maintain the spirit of this awesome community as it grows. diff --git a/community/elections/2017/calebamiles_bio.md b/community/elections/2017/calebamiles_bio.md deleted file mode 100644 index 452035a8..00000000 --- a/community/elections/2017/calebamiles_bio.md +++ /dev/null @@ -1,52 +0,0 @@ -# caleb miles - -## Contact Information - -- GitHub/Slack: @calebamiles -- Email: caleb.miles@coreos.com - -### Problem solving style - -I am a huge fan of ideas which simplify and unify, possibly due to my -undergraduate study of physics and mathematics. I believe that collaboration is -incredibly important and that continuous feedback on incremental solutions are -likely to produce the best outcome. I therefore try spend a lot of time talking -with people about the problems that are important to them before stepping back -to try to introduce a minimal solution based on their concerns. - -### Problems that are important to me - -I believe that addressing the dual challenge of communicating what everyone is -working on to other developers, and then explaining that work to users is one -of the most pressing issues for Kubernetes today. - -I also believe that we need to invest in the contributor experience particularly -by better supporting new contributors with mentorship programs, especially for -the self taught, new graduates, and underrepresented communities. If we are -going to be a successful and sustainable project we need to ensure that we -maintain a healthy pipeline of new contributors while at the same time reducing -the workload for more established contributors. - -Scaling contributions is another serious challenge for the project and I am very -interested in working on helping to support the effort to rethink the Kubernetes -release process. - -### Roles held - -I joined the community in 2016 since then I have made shallow contributions to - -- SIG Contributor Experience -- SIG Release -- SIG PM -- SIG Testing - -as well as serving in a minor capacity in the 1.5, 1.6, 1.7, and 1.8 releases. I -currently help to facilitate - -- SIG PM, co lead and co founder -- SIG Release, co lead and co founder - -### Where I work - -CoreOS - diff --git a/community/elections/2017/derekcarr_bio.md b/community/elections/2017/derekcarr_bio.md deleted file mode 100644 index 4f0f757a..00000000 --- a/community/elections/2017/derekcarr_bio.md +++ /dev/null @@ -1,43 +0,0 @@ -# Derek Carr - -- GitHub: @derekwaynecarr -- Employer: Red Hat - -## Roles Held - -- Co-founder, lead: sig-node, wg-resource-management -- Participate: api-machinery, autoscaling, federation, scheduling, - service-catalog - -## About me - -I joined in 2014 as an early external contributor. After the first developer -summit, I realized I had a lot to learn from the experience of others. My first -PR enabled people to contribute to the project by running Kubernetes in a VM. -Mentors in the community helped multiply the quality of my contributions. With -their help, I designed and implemented namespaces, quota, limits, and much of -the supporting internal machinery like admission control, indexers, and clients -prior to the 1.0 release. - -As the project grew, SIGs developed to support specialized collaboration. I -co-lead SIG node and advocate for expanded workload support and improvements to -node reliability. To improve cross-SIG collaboration, I co-founded the Resource -Management Working Group to define a multi-release roadmap across SIGs (node, -scheduling, storage, etc). The cross-SIG working group concept has been adopted -across the community. I participate in multiple incubator projects with code -and coaching on technology and process. As every maintainer acknowledges, it is -impossible to know everything about Kubernetes. I prioritize mentoring others to -help them grow their scope and sustain the project. - -My experience reflects both a breadth and depth of commitment across Kubernetes -that would benefit the committee. I have a pragmatic approach to problem -solving that builds from the expertise of others and adopts minimal solutions -that have the best potential outcome. I iterate and improve. As a member of -the community, I hope the steering committee adheres to the same general -approach. - -## Where I see myself contributing - -- Responsibly grow contributor pool across all disciplines -- Clarify scope, structure, and responsibilities of SIGs and roles within -- Enhance Code of Conduct to nurture an inclusive, diverse, and open community \ No newline at end of file diff --git a/community/elections/2017/dougdavis_bio.md b/community/elections/2017/dougdavis_bio.md deleted file mode 100644 index 4a80fd85..00000000 --- a/community/elections/2017/dougdavis_bio.md +++ /dev/null @@ -1,40 +0,0 @@ -# Doug Davis - -- Github: [@duglin](https://github.com/duglin) -- Works for: IBM - -## Background - -I've been working on open source projects, and standards, for about 17 years, -starting with being a co-initiator of the Apache Axis project; working on -WS-* related projects and specifications, OpenStack, CloudFoundry, Docker -and now Kubernetes, including as a co-lead of the Service-Catalog Incubator. -I also founded the Web Services Testing Forum, a consortium of Web Service -providers and consumers designed for interop testing of SOAP/WS-* -specifications, as well as the [soaphub](http://soaphub.org) on-line -collaboration chat tool used by several communities. - -Throughout this time the importance of an open, fair and streamlined -collaboration process has really been a center piece of my activities and -goals for these projects. - -## Steering Committee - -The stated scope of the Steering Committee focuses on helping the -Kubernetes community define and optimize many of the (sometimes less than -glamorous, but necessary) processes and infrastructure that's critical -to keeping a community like Kubernetes healthy and successful. - -Kubernetes, as one of the fastest growing OSS projects, needs to navigate -and manage the complexities associated with this explosive growth very -carefully. The importance of balancing the need for continued enhancements, -managing stability of the code base, all while ensuring the community of -developers and users feel their contributions (from code, issues and feedback) -are welcome, respected and addressed in a timely fashion can not -be understated. This will require people who can consider the challenges -from multiple perspective, not just from a developer's. - -I believe that my background in the open communities I've been involved with -have given me a good perspective on what works, what doesn't and which might -be best for an organization like Kubernetes. - diff --git a/community/elections/2017/errordeveloper_bio.md b/community/elections/2017/errordeveloper_bio.md deleted file mode 100644 index a667a2b4..00000000 --- a/community/elections/2017/errordeveloper_bio.md +++ /dev/null @@ -1,33 +0,0 @@ -# [Ilya Dmitrchenko](https://github.com/errordeveloper) - -## Manifesto - -Ilya has been contributing to Kubernetes since 2014. The focus of his contributions has been on solving -general cluster provisioning and bootstrap problems and making networking easier. For example in 2016, -he did the groundwork on the initial version of `kubeadm`. - -Ilya is a DX engineer at Weaveworks and is based in London. From there he travels (mostly in Europe) to -educate the wider community about the benefits of containers and orchestration with Kubernetes. Ilya -would be delighted to represent the European users as a member of the steering committee. - -Most recently, he started participating in organised community activities whose aim is to solve the -problems and the needs of end users who have Kubernetes in production or who are looking to put it in -production. To that end, he is a member of the London Production User Council, and together with other -contributors launched Kubernetes Office Hours. - -To learn more about Ilya's background and why he deeply cares about the community, please take a look at -his [personal blog](https://medium.com/@errordeveloper/a-little-more-about-me-b0b6238ba7f8). - - -## Key Priorities - - - Customer success with open-source Kubernetes - - Ease of use, in majority of general cases - - Growth of the community, and fairness - - Social and technical diversity - -## More Info - - - [Personal projects](https://github.com/errordeveloper) - - [Tweets](https://github.com/errordeveloper) - - [Personal blog](https://medium.com/@errordeveloper/a-little-more-about-me-b0b6238ba7f8) diff --git a/community/elections/2017/idvoretskyi_bio.md b/community/elections/2017/idvoretskyi_bio.md deleted file mode 100644 index c4e8c002..00000000 --- a/community/elections/2017/idvoretskyi_bio.md +++ /dev/null @@ -1,24 +0,0 @@ -# Ihor Dvoretskyi - -Twitter: https://twitter.com/idvoretskyi - -GitHub: https://github.com/idvoretskyi - -Anywhere else: @idvoretskyi - -## About me - -I'm a [Developer Advocate for Cloud Native Computing Foundation](https://www.cncf.io/blog/2017/09/18/meet-cncfs-newest-developer-advocate/), open source lover, passionate about the technologies and open source adoption; with the deep technical background, together with program and product management experience in the open source world. In a previous life, I’ve been a System Administrator and DevOps Engineer, passionate about the Cloud technologies. Later, I’ve joined Mirantis, one of the largest players in the OpenStack world, where I’ve started my collaboration with OpenStack community. - -I've enjoyed Kubernetes since the early days. I've started researching it in mid-2014 when it was publicly announced; I've been using for my projects it in mid-2015 when it had reached its 1.0 milestone; and I've started contributing (as an individual contributor) to Kubernetes in late-2015, when I felt that my knowledge and experience might be useful for the project. - -As a Kubernetes Community member, I'm mostly focused on Product- and Project-management areas, with the primary interest in the features and roadmap scope. -For Kubernetes 1.3, 1.4 and 1.5 I've been unofficially involved in the release process with the features tracking and management. -Since Kubernetes 1.6 release cycle (and continued these efforts during 1.7 and 1.8), I've joined the release teams as the release manager, responsible for the features. -Finally, I've been one of the co-founders of [SIG-PM](https://github.com/kubernetes/community/tree/master/sig-product-management), responsible for managing Kubernetes-as-a-project and Kubernetes-as-a-product. - -Besides that, as an individual with OpenStack community background, I'm co-leading [SIG-OpenStack](https://github.com/kubernetes/community/blob/master/sig-openstack/README.md), building the relationships between two major open source communities. - -## What's next? - -As a vendor-neutral Kubernetes contributor, I'm going to continue my work on enhancing Kubernetes as an open source project, technology stack, and one of the largest open source communities in the world. diff --git a/community/elections/2017/jaicesingerdumars_bio.md b/community/elections/2017/jaicesingerdumars_bio.md deleted file mode 100644 index 90ba0ee3..00000000 --- a/community/elections/2017/jaicesingerdumars_bio.md +++ /dev/null @@ -1,20 +0,0 @@ -# Jaice Singer DuMars - -## Contact Information - -- GitHub: [@jdumars](https://github.com/jdumars) -- Twitter: [@jaydumars](https://twitter.com/jaydumars) -- LinkedIn: [Jaice Singer DuMars](https://www.linkedin.com/in/jasondumars/) -- Works for: Microsoft - -## Why me? - -The steering committee represents a unique convergence of my passion for servant leadership, organizational dynamics, inclusion, advocacy, and process optimization. It's always my highest purpose to be a voice and advocate for those I serve. And, if elected, I will faithfully serve the ever-changing, sometimes divergent, and always important needs of the Kubernetes community. - -## Servant leadership - -Since my first moments in the community, I have sought out every opportunity I can to make things better. I wrote an article about this called [What Kubernetes means to me](http://bit.ly/k8s2me) that will shed some light on my journey to this point. My contributions to the community currently include leading the 1.8 release team, co-leading SIG Azure, SIG Architecture, and SIG Cluster Ops (although Rob Hirschfeld has been covering for me while I work on the release). I have facilitated every release retrospective since 1.3, and have improved my typing skills by note taking at countless SIG meetings. I also work behind the scenes on Community things with Sarah and Jorge. - -## Career - -I've been in love with systems, networks, and the human elements of interconnectivity since I was a SysOp on a BBS as a teenager. My first hack was in grade school, making the Oregon Trail game say naughty things. In the time since, I have been a systems and network engineer, and held several engineering management directorships at companies large and small. At Microsoft, all I do is Kubernetes, so I definitely have the organizational support to carry out my duties on the committee. diff --git a/community/elections/2017/kris-nova_bio.md b/community/elections/2017/kris-nova_bio.md deleted file mode 100644 index 371379d4..00000000 --- a/community/elections/2017/kris-nova_bio.md +++ /dev/null @@ -1,36 +0,0 @@ -# Kris Nova - -## What is important to me - -Mental, philosophical, and design diversity. Period. - -I truly believe that the best teams and projects are those that embrace unique and sometimes conflicting ways of thinking. - -Having a leadership board of people who all think the same way, and all are moving in the right direction is stale and stagnant. - - - I want to help foster diversity in Kubernetes in both our design process, but also our goals and philosophies. - - I want to encourage my peers to put themselves into difficult, or testing situations in order to help grow and mature. - - I want to let others know that it's okay to try something and fail as we all learn as a scientific community. - - -## Work in the community - - - I spend as much of my free time as humanly possible contributing to Kubernetes. - - I take impromptu video calls with total strangers. - - I helped run *sig-aws* even though it conflicted with my dayjob. - - I created [kubicorn](https://github.com/kris-nova/kubicorn) in my free time and it has been reviewed as one of the best open source projects to contribute to in the space. - -## Reasons to pick me - -## I think differently. - -I question the world around me, and have been in a ton of different roles in engineering space. Including time in both genders. - -## I believe that software comes first. - -I love kubernetes regardless of my employer, and will always contribute because I believe in it. -I believe the way we continue to keep the project great is to focus on community, as well as writing kick ass software with a great user interface. - -## tldr - -I embrace being different and want to clean up our code and improve user experience. \ No newline at end of file diff --git a/community/elections/2017/mattfarina_bio.md b/community/elections/2017/mattfarina_bio.md deleted file mode 100644 index 2f4e6db9..00000000 --- a/community/elections/2017/mattfarina_bio.md +++ /dev/null @@ -1,23 +0,0 @@ -# [Matt Farina](https://www.mattfarina.com) -Technical leader, coder, author, presenter - -## Governance and Organization - -The steering committee is [chartered](https://github.com/kubernetes/steering/blob/master/charter.md) with figuring out the governance and organization of the Kubernetes community. Matt has years of experience in both non-profit and open source organizations. He has served on the board for two non-profits along with being involved in open source projects with mature governance models (e.g., Drupal and OpenStack). - -Matt believes that governance should enable people to easily navigate an organization and be empowered to be part of the community. That groups within an organization, such as special interest groups (SIG) and working groups, should have clearly communicated scope. This helps everyone understand how the organization is laid out while helping to highlight gaps. - -He also believes in diversity. This includes diversity of ideas and uses for Kubernetes. Diversity brings out ideas that can often be missing in an echo chamber of similar people with similar uses cases. Diversity leads to a stronger Kubernetes that's more capable of meeting real world needs. - -Matt wants to see Kubernetes as a professional community with an enjoyable experience for both contributors and consumers. - -## Technical Background - -Matt has been a contributor of open source for 15 years and a consumer of open source for over 20 years. In that time he has contributed to projects such as [Glide](https://glide.sh) (package manager), [Drupal](https://drupal.org), [OpenStack](https://www.openstack.org), and many others. While working in and out of open source Matt has had a focus on both software development and _user experience_. - -He has also authored technical books, hosted podcasts, and presented at numerous conferences. This has taught him how to clearly communicate with a wide variety of people. - -## Quick Details - -* Co-founded and co-leads SIG Apps -* Works for [Samsung SDS](https://samsung-cnct.github.io) diff --git a/community/elections/2017/michaelrubin_bio.md b/community/elections/2017/michaelrubin_bio.md deleted file mode 100644 index 09a4c5f7..00000000 --- a/community/elections/2017/michaelrubin_bio.md +++ /dev/null @@ -1,36 +0,0 @@ -# Michael Rubin Bio - -GitHub: @matchstick - -## About Me - -I have been a software engineer, technical manager, and leader for -~20 years. I am passionate about helping projects and people thrive. -Today I lead a number of Kubernetes teams at Google, including Storage, -Networking, Multi-cluster, Node, and more. - -I love coding and technology, but even more than that I love mentoring -others and helping them to have impact and grow professionally. This is -why I choose to support teams and projects as a technical manager. - -My leadership style is to bring sharp focus to technical efforts, and -to help others become successful leaders, themselves. I find that many -technology problems are not purely technical, and one of my biggest -strengths is my ability communicate, connect with people, and get to -the root of a problem. People are not machines, and they need different -skills than just pure engineering. - -During my 1.5 years with Kubernetes, I have worked directly and -indirectly with several SIGs - Storage, Multi-cluster, Networking, -Scheduling, and Node. I think I have brought clarity and structure to -the efforts, helped organize priorities and roadmaps, and helped the -teams and individuals grow. I have built lasting relationships with -the people of Kubernete, and not just the code. - -As a member of the Steering Committee, I would focus on: - - * Cross SIG efforts and how to co-ordinate them - * Getting more things out of core, but keeping them part of Kubernetes - * Maintain the cool, open and inviting environment we have today - * Delegate and empower others by adding structure (not process) - diff --git a/community/elections/2017/michellenoorali_bio.md b/community/elections/2017/michellenoorali_bio.md deleted file mode 100644 index 6d9faa0e..00000000 --- a/community/elections/2017/michellenoorali_bio.md +++ /dev/null @@ -1,35 +0,0 @@ -# Michelle Noorali - -GitHub: [@michelleN](https://github.com/michelleN) - -Twitter: [@michellenoorali](https://twitter.com/michellenoorali) - -LinkedIn: [Michelle Noorali](https://www.linkedin.com/in/michelle-noorali-a588b516) - -## History & Roles Held - -- Working with Kubernetes and have been part of the community since mid-2015 -- Co-founded and Co-lead Kubernetes SIG Apps for focusing on defining and managing applications in Kubernetes -- Core Maintainer of the Kubernetes Helm project -- Co-chair CloudNativeCon & KubeCon 2017 - -## Why I'm here - -The Kubernetes community has been a special place for me, and I'm glad to be part of it. I have found it exciting to work collaboratively with folks from different organizations, backgrounds, parts of the world, and industries on problems that matter to all of us sometimes even for different reasons, so I enjoy and place great value on communicating effectively and balancing different perspectives for technical solutions. - -Because Kubernetes is such an empowering piece of technology, I am obsessed with helping make sure that it is usable across audiences. This is where the bulk of my work with [SIG-Apps](https://github.com/kubernetes/community/tree/master/sig-apps) comes in. We've been working for almost a year and a half on making the process of defining and managing applications in Kubernetes easier and the best experience possible. Throughout this process, we've repeatedly re-defined how our SIG functions and how it can best serve the community. We focused on creating a tight feedback loop with the folks who consume apps features in Kubernetes and those who help create and maintain those features. We share solutions to common sets of problems, and we ensure that the solutions presented are set up for success by helping our presenters set the right context for the audience. We even focus on the flow of our meetings to make sure that people are able to follow along making the SIG content digestable, empowering newcomers in the space, and helping funnel more opinions into feedback loops. I believe SIGs are a fundamental part of the Kubernetes community and one of the big reasons the community is so successful. I am particularly passionate about supporting SIGs and making them even stronger than they are today using my experience with SIG Apps. - -Lastly, it has been rewarding for me to help people begin their journey in the Kubernetes community by guiding them to the right place to get what they need. I've enjoyed being part of the growth of this community and want to ensure that it remains an approachable one as well as an inclusive place to work. - -## Key priorities - -- Making sure people are heard -- Making sure opinions are respected -- Helping ensure the right context is set when discussing concerns and ideas -- Helping people be successful in whatever area they are in -- Empowering newcomers -- Empowering SIGs and SIG leads - -## Where I work - -Microsoft Azure, previously Engine Yard/Deis diff --git a/community/elections/2017/pwittrock_bio.md b/community/elections/2017/pwittrock_bio.md deleted file mode 100644 index a6defb9b..00000000 --- a/community/elections/2017/pwittrock_bio.md +++ /dev/null @@ -1,55 +0,0 @@ -# Phillip Wittrock Bio - -GitHub: @pwittrock - -## Problem solving style - -- Incremental approach to problem solving -- Try new things - build and iterate on minimalist solutions - -## What I find important - -I care deeply about helping people feel positive about what they are doing and empowered to do more. -Within the Kubernetes community, I would like to focus on helping ensure contributors': - -- time and contributions are impactful -- time and contributions are recognized and appreciated -- opinions are listened to and valued - -## Where I see myself contributing - -I believe it is important for the processes for contribution and maintenance of the project -to be well communicated and understood within the community. -I would like to be involved in areas owned by the SC such as - helping to develop a -SIG charter template, simplifying the contributor ladder, documenting resources the community has, -and helping to find a home for unowned areas of the project. - -## Roles held - -Since joining the community in 2015, I have made contributions in various roles -(developer, SIG-lead, docs, release manager) across the project. Working -in these capacities has given me insight into the challenges faced throughout the project. - -Areas of the project I have contributed to include: node, kubectl, service catalog, docs and release. - -### Current SIG lead positions I hold - -- Co-founded SIG-cli -- Co-founded SIG-release - -### Emeritus SIG lead positions I have held (brief tenure) - -- Bootstrap SIG-contribX -- Bootstrap SIG-docs - -### Relevant non-technical contributions - -- (release) Changed management role from an individual to a team with defined roles -- (release) Proposals for streamlining and automating various processes -- Published community membership ladder developed from draft (draft by Brian Grant) -- 1.4 release czar -- Participated in 1.5, 1.6 and 1.7 releases - -## Where I work - -Google \ No newline at end of file diff --git a/community/elections/2017/quintonhoole_bio.md b/community/elections/2017/quintonhoole_bio.md deleted file mode 100644 index d72d6aa0..00000000 --- a/community/elections/2017/quintonhoole_bio.md +++ /dev/null @@ -1,66 +0,0 @@ -# Quinton Hoole - -- Github: [quinton-hoole](https://github.com/quinton-hoole) - -# About Me - -Currently I'm Technical Vice President of Cloud Computing At Huawei -Technologies (185,000 employees globally, US$75BN annual revenue -(2016), 32% annual revenue growth). - -I was the founding engineer of Amazon EC2 (2005-2010). - -I was the lead engineer at Nimbula.com (2010-2012), a Cloud IaaS -startup which was acquired by Oracle in 2013. - -I was at Google from 2012-2016, first as Technical Lead and Manager of -Ads Serving SRE, and then Engineering Lead on the Kubernetes team -(2014-2016). - -Prior to 2005, I co-founded two startups (one in the online travel -industry, the other in financial services), on both of which I served -as lead techie until they were acquired by public companies. I have -also worked as a consultant, contractor and technical leader in the -telco, financial and retail industries. - -I have an M.Sc in Computer Science. - -# Highlights of What I've done on Kubernetes thus far - -Initially I led the effort to get our CI Testing stuff initiated and -[working effectively](https://github.com/kubernetes/community/blob/master/contributors/devel/writing-good-e2e-tests.md), which was critical to being able to launch v1.0 successfully, -way back in July 2015. Around that time I handed it over to the now-famous SIG-Testing. - -After that I initiated and led the [Cluster -Federation](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/federation/federation.md) -effort, which has spilled over and touched many aspects of Kubernetes -in one way or another (API, Networking, Security, Scalability, Resiliency, -Testing etc). - -Along the way I also helped the [Scalability folks to set some key -objectives](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md). - -# How I Hope to Serve You on the Steering Committee - -I am a strong believer that Cloud Computing will change the world -(even more so than it already has), and that Kubernetes is the next -big step in this exciting journey. - -To realize this potential, I believe that we need to create both a -thriving, collaborative community, and freaking awesome software that -people love to use, everywhere. We're doing pretty well in both of -these areas, but there's still a lot of room for improvement. So I'd -like to offer my broad and deep experience, time and passion to help -us to get there. Hopefully my track record will help to convince you -that I'm fairly good at identifying good things for us to do, figuring -out how best to do them, and getting them done. Along the way I have -accumulated more than a few scuffs and bruises, as well as a few -victories, so hopefully I can help us to avoid some of the former. - -More specifically, I'd like to help us to (amongst others): - -- ensure that Kubernetes remains a fun place to develop stuff that - people love to use. -- create effective incentives to motivate constructive, productive - and sustainable progress. -- protect what we have built (and will build) from bad things happening. diff --git a/community/elections/2017/rhirschfeld_bio.md b/community/elections/2017/rhirschfeld_bio.md deleted file mode 100644 index c3994be7..00000000 --- a/community/elections/2017/rhirschfeld_bio.md +++ /dev/null @@ -1,27 +0,0 @@ -# Rob Hirschfeld Bio - -* GitHub: [@zehicle](https://github.com/zehicle) -* Twitter: [@zehicle](https://twitter.com/zehicle) -* Blog: [RobHirschfeld.com](http://robhirschfeld.com) -* I work at [RackN.com](https://RackN.com) and live in Austin, Texas. - -## Governance Perspective: it's about people, not tech - -Open source infrastructure automation is a critical foundation for the Internet and, thus, advancing society as a whole. In a very practical way, protecting open software is essential to building a better world. I am seeking a seat on the Kubernetes Steering Committee because I bring special perspectives to governing the project. - -## Leadership: Technical, Open Source and Business - -I’ve demonstrated practical and relevant experience to building open governance at this stage in our development. - -* **Open source project founder ([Digital Rebar](http://rebar.digital), Crowbar)**: I know the challenges of sustaining contribution -* **Operator**: I’ve run infrastructure and founded the SIG Cluster Ops group to give a voice for operators. I focus professionally on helping promote SRE and DevOps practices. -* **Founding OpenStack board member (4 terms)**: I’ve built open governance processes and done the hard work to build conformance and core definition (#DefCore) patterns. -* **Start-up founder (RackN.com)**: I’ve done every role and am willing to get my hands dirty. I understand the needs for small companies trying to support large projects. -* **Dell Executive**: I’ve been part of large organizations and know how to explain things in corporate speak to protect project interests. -* **Technologist**: I still write code and build applications as needed so I understand the very specific concerns of delivering working platforms. - -## TL;DR: Collaborative and Principled - -Most importantly, I’m collaborative by nature. I know how to stand my ground and fight without being a jerk or excluding people. I can be one of the advocates that the Kubernetes community needs as we build formal governance. - -_Governance means being able to say no and keep consensus._ diff --git a/community/elections/2017/sebastiengoasguen_bio.md b/community/elections/2017/sebastiengoasguen_bio.md deleted file mode 100644 index 065bf8eb..00000000 --- a/community/elections/2017/sebastiengoasguen_bio.md +++ /dev/null @@ -1,30 +0,0 @@ -# Sebastien Goasguen - -## Contact - -* GitHub: [@sebgoa](https://github.com/sebgoa) -* Twitter: [@sebgoa](https://twitter/sebgoa) -* Linkedin [Profile](https://www.linkedin.com/in/sebastien-goasguen-382b7b21/) -* Employer: Bitnami - -## Vision - -Being a member of the steering committee is not a technical role, it is a temporary position to help the community grow and ensure that the project (at large) succeeds in the long term. - -The steering committee already has a long backlog of things to do and I submitted a [PR](https://github.com/kubernetes/steering/pull/2) some time ago to show my take on it. Within that backlog, I see three main areas that need a lot of clarity. - -* Membership. Our membership and roles have grown organically, driven by our velocity and the limitations of GitHub. I would like to see us step back a bit and clearly define our membership ladder and ways by which contributors navigate it. This would provide clear criteria for example to define who is a "person of standing" and how you become one. - -* Decision making. We have a lot of slack channels, hangouts and mailing lists. However we do not know where decisions are made, when and how. We need to bring clarity to our decision making processes so that everyone feels that they own the decision. It is also a major issue of inclusiveness which can lead to fragmentation of the community. - -* Incubator. We have an incubator but I believe we need to revise its "charter" now that several projects have graduated. We need more mentoring and support of the incubating projects. Moreover, the graduation criteria, need to encompass a more visible decision process (currently only 2 people decide if a project graduates). - -My experience at the Apache Software Foundation (member and part of several project management committee) can be extremely helpful. Not to apply the exact same principles and processes but to find a balance and bring a perspective from an established open source foundation that is totally vendor neutral, based on meritocracy, has an incubator and clear decision making processes. - -## Diversity - -My name is in a French dialect (Breton), it literally means "white man". However Kubernetes is a worldwide community and I believe it needs representation from different nationalities, cultural background and from people who do not necessarily speak English as their mother tongue. I believe I can be that little voice which brings a bit of balance in an otherwise heavily US dominated steering committee. - -## Kubernetes Background - -I have been involved with Kubernetes since [Sept 2014](https://github.com/kubernetes/kubernetes/pull/1411) and focused on tools in the ecosystem. My startup [Skippbox](https://github.com/skippbox) created several tools including: kompose, kmachine, Cabin and [kubeless](http://kubeless.io). We joined Bitnami in March 2017 where I lead all our Kubernetes efforts. I helped very early on with Helm and Charts. I try to help with the Python client and mentored a GSoC student this summer. I also do a fair share of advocacy and training and I am the co-author of the upcoming Kubernetes cookbook. diff --git a/community/elections/2017/timothysc_bio.md b/community/elections/2017/timothysc_bio.md deleted file mode 100644 index 9daeee9f..00000000 --- a/community/elections/2017/timothysc_bio.md +++ /dev/null @@ -1,26 +0,0 @@ -# Timothy St. Clair - -## Contact Information - -- GitHub/Slack: [@timothysc](https://github.com/timothysc) -- Email: tstclair@heptio.com -- Twitter: [@timothysc](https://twitter.com/timothysc) - -## Background - -I've been involved in the Kubernetes project since 2014, and prior to that I was an active member in the Mesos community, with over 10+ years of experience working on open source projects across a plethora of communities. During my tenure, I've been lucky enough to meet a number of great folks working on various SIGs: - -- SIG Scheduling & Testing (Lead) -- SIG Scale, Cluster Life-cycle, API Machinery, Node (Contributor) - -## Why I want to be on the Steering Committee (Optimize, Simplify, and Empower) - -Time is our most precious commodity, and few things can be more frustrating than wanting to contribute only to watch patches bit-rot, have legitimate issues sit unaddressed, or type `/retest` for the 10th time. My primary goal in running for a position on the steering committee is optimize processes such that no one feels like their time is wasted working on this project. As of today, the process that a contributor needs to follow is byzantine, and can be daunting for folks who are new to the community. (Optimize) - -However, it doesn't stop there. In order for the community to thrive, we need to continually reevaluate our processes to ensure what we are doing makes sense, and ensure those processes are simple and concise. (Simplify) - -Lastly, I want to help promote and empower folks in the community to take on some of the roles that have traditionally been filled by google. Once core aspects of the test and release process can be done by non-googlers I think we've reached a point where we have empowered the broader community. (Empower) - -## Where I work - -Heptio diff --git a/community/elections/2017/vote_for_justinsb.md b/community/elections/2017/vote_for_justinsb.md deleted file mode 100644 index bae8ece2..00000000 --- a/community/elections/2017/vote_for_justinsb.md +++ /dev/null @@ -1,43 +0,0 @@ -## Vote for justinsb! - -You can see my full "manifesto" [here](https://groups.google.com/d/msg/kubernetes-dev/YawXYxGHWEg/IlLN-iD6CgAJ); we've been asked to provide a shorter summary here. - -This election is critical. The steering committee is not an honorary position; -it has effectively unlimited powers. Serving is a duty, not a privilege, and I -humbly ask for your vote. - ---- - -I have been involved with Kubernetes since before 1.0, primarily on AWS support -(I am a lead of sig-aws), but also contributed the original multi-zone & -NodePort support. I also started the kops project, to produce an open-source -and consistent Kubernetes installation tool. I'm an independent, working with -Kubernetes in my day job but not employed to contribute to it, so I contribute -instead where I see a problem or an unmet need. - -If elected, I will serve wearing my own two hats: that of a developer on -the project contributing because it is a positive personal experience, and that -of an end-user of Kubernetes valuing a stable and straightforward product. - -I believe I bring particularly strong experience on non-GCE, non-Redhat -platforms, and on the realities of maintaining projects outside the core repo. -I think these are likely to be some of the most challenging areas for the -steering committee. - -## My manifesto: - -(Abbreviated from [here](https://groups.google.com/d/msg/kubernetes-dev/YawXYxGHWEg/IlLN-iD6CgAJ) ) - -* Reach decisions quickly & consistently; communicate them clearly. - -* Value a clear and efficient developer process. - -* Empower the release team with the goal of producing a more stable release. - -* Figure out how to delegate to SIGs without creating fiefdoms. - -* Streamline our processes. - -* Promote experimentation with alternative processes amongst our many projects, -balancing against the need for a consistent experience, allow the best approaches to "bubble-up". - diff --git a/community/elections/README.md b/community/elections/README.md deleted file mode 100644 index 14a1ea3f..00000000 --- a/community/elections/README.md +++ /dev/null @@ -1,96 +0,0 @@ -## Kubernetes Elections - -This document will outline how to conduct a Kubernetes Steering Committee Election. See the [Steering Committee Charter](https://git.k8s.io/steering/charter.md) for more information of how the committee decides when to have an election, the method, and the maximal representation. - -## Steering Committee chooses Election Deadlines and Officers - -- Steering Committee selects the Election Officers -- Dates should be in UTC time, use a [world clock service](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Election+Test&iso=20181101T00&p1=%3A&ah=10) in documentation and email announcements so that end users see the correct time and date based on where they live. - - -### SC Selects the following dates: - -- Recommend the month of October to not collide with a release or end of a quarter. -- Nomination and Voter Registration period start -- Nomination period end (At least a two week period) -- Voter Registration Deadline -- Link to voter registration process (doesn’t exist yet) -- Election period start - - It takes time to create the poll in CIVS, so don’t give a specific hour, instead say “Morning of the 10th” or something vague. -- Election period stop - - CIVS needs to be manually stopped, so an actual person needs to click for the poll to stop, so this needs to be a human friendly time. -- Results announcement date - -## Process - -1. Election officers prepare the election repository - - Make github.com/kubernetes/community/elections/$YEAR - - Make github.com/kubernetes/community/elections/$YEAR/README.md, this is the voter’s guide. - - Copy over the voter’s guide from the previous year. The voter’s guide is the single source of truth for the election that year! All announcements and notices should link to this document. - - Update with new dates, candidates, and procedures (if necessary). - - Announce to the candidates to submit PRs with their platform statement (if they desire), 300 word limit. Each platform document lives in the elections/$YEAR directory, with the voter’s guide (README.md) acting as the index. - -2. Announce voting schedule to community - -- Should mostly be links to the voter guide and the Steering Committee Charter -- On kubernetes-dev list, kubernetes-dev slack, and twitter - -3. Executing the Election in CIVS - -- Use [CIVS](http://civs.cs.cornell.edu/civs_create.html) to create the election, which CIVS calls a poll. Once you send out the ballots you cannot UNSEND the emails, ensure everything in the form is correct! -- Name of the poll - “Kubernetes Steering Committee Election for $YEAR” -- Name of supervisor - “Kubernetes Steering Committee” -- Email - elections@kubernetes.io : Googlegroups doesn’t work here. This mail should resolve to members of the steering committee AND the election officers. -- Date and Time: Write in the date and time the election will stop. This field is not programmatic, the election is stopped by hand, so you can write this in plain text. -- Description: This election is to nominate the steering committee for the Kubernetes project. Select the three(3) candidates, by order of preference. Please see the voter's guide for more information. PLEASE NOTE: "No opinion" is also a voting option if you do not feel comfortable ranking every single candidate. -- Add the candidate list to the form -- How many choices will win: This number needs to be set to the amount of open seats of a given election -- More options, check the boxes for: - - Do not release results to all voters. - - Enable detailed ballot reporting. - - Allow voters to select “no opinion” for some choices. -- Click create poll, this will send elections@kubernetes.io an email with instructions. -- It will send you a link to “Poll Control”, bookmark this generated page as this is where you will add voters and also resend ballots to people if their ballot gets lost or filtered. -- This page is where the “Start Poll” and “Stop Poll” buttons are, start the poll. -- Paste in the registered voters and click add voters. - - It will mail the ballots to the participants. - - It does duplicate detection so multiple entries are fine. -- Leave the poll open for the duration of voting. - - Remember to send a 24 hour reminder before closing the poll. - -## Roles and Responsibilities: - -### Steering Committee - -- Select election dates -- Select Election Officers -- Select criteria for Kubernetes Members of Standing -- Must refrain from endorsing or otherwise advocating for any candidate -- Is allowed to vote in the election -- Announces results of the election to the community -- Commit the results of the election to the Kubernetes Community repository - -### Election Officers - -- Must be a Kubernetes Member of Standing -- Cannot be running for office in the current election -- Cannot be a current member of the steering committee -- Generates the voter guide -- Tracks candidates -- Monitors kubernetes-dev for nominations - - Keeps track of nominees in a spreadsheet - - Ensures that each nominee has the required nominations from three different employers (as stated in the charter) - - All nominations are conducted in the public, so sharing this sheet during the nomination process is encouraged -- Accepts/Reviews pull requests for the candidate platforms - - The community generally assists in helping with PRs to give the candidates a quick response time -- Update the community regularly via the community meeting -- Post on behalf of the steering committee if necessary -- Posting deadlines and reminders to kubernetes-dev, twitter, and slack. -- Reissues ballots from CIVS to voters who might have not received their ballot. -- Miscellaneous election related tasks as decided by the steering committee. -- Must refrain from endorsing or otherwise advocating for any candidate. -- Must refrain from discussing the election specifics during the election period. -- Guard the privacy of the email addresses of voters -- It is impossible for the election officers to see the results of the election until the election ends; for purposes of transparency with the community it is encouraged to release some statistics during the election (ie. “65% of the community has voted so far!”) -- Ensure that the election results are handed over to the steering committee. -- Is allowed to vote in the election \ No newline at end of file diff --git a/community/office-hours.md b/community/office-hours.md deleted file mode 100644 index 3d7aa8c8..00000000 --- a/community/office-hours.md +++ /dev/null @@ -1,76 +0,0 @@ -# Kubernetes Community Office Hours - -## UPDATE: NO OFFICE HOURS UNTIL 2018, Happy Holidays! - -Office Hours is a live stream where we answer live questions about Kubernetes from **users** on the [YouTube channel](https://www.youtube.com/c/KubernetesCommunity/). Office hours are a regularly scheduled meeting where people can bring topics to discuss with the greater community. They are great for answering questions, getting feedback on how you’re using Kubernetes, or to just passively learn by following along. - -**Special Pilot Edition - Contributor Office Hours** -This special office hours pilot will cater to upstream Kubernetes contributors with one off questions being answered from current members of standing with the project. - -Example Questions: -What SIG do I join? -What to do when there is a lot of back and forth on an issue? -What's going on with the tests? -...bring these questions live or to the #office-hours slack channel - -Pilot will take place: -Nov 29th, 2017 at 9am PST / 17:00 UTC on Zoom: https://zoom.us/j/921352437 -If the pilot does well, we will update this with further information including the regular schedule of sessions. - -### When and Where - -Third Wednesday of every month, there are two sessions: - -- European Edition: [2pm UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Kubernetes+Office+Hours+%28European+Edition%29&iso=20171115T14&p1=136&ah=1) -- Western Edition: [9pm UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Kubernetes+Office+Hours+%28Western+Edition%29&iso=20171115T13&p1=1241) - -Tune into the [Kubernetes YouTube Channel](https://www.youtube.com/c/KubernetesCommunity/live) to follow along. - -You can post questions on the [#office-hours channel](https://kubernetes.slack.com/messages/office-hours) on Slack, or if you like you can submit your question to Stack Overflow and have us take a look. - -### How it Works - -#### Bringing your own Stack Overflow Question - -If you submit a [SO question](https://stackoverflow.com/questions/tagged/kubernetes) we can prepare ahead of time and check important details. - -As a thanks to the community the person asking the question can then ensure that a well written answer makes it way to the question afterwards so that we can build a knowledge base and help maintain the incoming questions. We can also use the video archive of each meeting to bring context to each SO question we answer. - -Questions that aren’t addressed or need work can be punted to the next week or we can encourage other people to give them a look, at a bare minimum we can at least help socialize the difficult questions. We keep a backlog of open questions in the [meeting notes](http://bit.ly/k8s-office-hours-notes). - -The hosts will do a shout out of thanks to the [current leaderboard](https://stackoverflow.com/tags/kubernetes/topusers) of SO answerers each meeting so the people helping answer questions can get some recognition. - -#### What’s Ontopic - -Specific questions about Kubernetes as pertaining to the topic. Since this is a Q&A format, we’d like questions that can be answered generally. So for example: - -- Bad: My ingress configuration is broken please fix it. (Dependent on local configuration) -- Good: My ingress configuration is broken can you discuss what problems you usually see and common mistakes that people make so I can avoid them? (Generalized and can communicate things that can help multiple people) -- Bad: How do I deploy my application in Kubernetes? (Easy to look up, tons of content on this) -- Good: What best practice techniques are there for deploying applications in Kubernetes? (Nuanced version lets us cover RBAC, application lifecycle) -- Bad: My pods aren’t coming up on a node. (Vague) -- Good: My pods aren’t coming up or misbehaving, what are the debugging steps to find out the root cause? (Helps us communicate the thought process for debugging to a general audience) - -#### What’s Offtopic - -Local installation and debugging: The participants don’t have access to your network or your hardware. The host can/should help the user transform a vague question into something answerable and reusable. - -Let’s try to not just dismiss bad questions outright, but use it as an opportunity for the answer to be a teaching tool as opposed to just answering “It’s in /var/log/foo, next question.” If the question is about logging then the developers might as well share their experiences in that area, recommend tools, share an anecdote, things of that nature. - - -### Archives - -Archives of all the sessions are kept here: - -- [Office Hours playlist](https://www.youtube.com/watch?v=D0Q7wwljN30&list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg) -- [Office Hours meeting notes](http://bit.ly/k8s-office-hours-notes) - - -### Volunteering - -We're always looking for volunteers to host and answer questions. Volunteers looking to host hours in -more time zones are also welcome to join in and help us expand. - -- [Volunteer working sheet](http://bit.ly/k8s-office-hours-volunteers) - -If you have any questions ping [@castrojo](https://github.com/castrojo). diff --git a/events/2016/Kubernetes_1st_Bday.md b/events/2016/Kubernetes_1st_Bday.md new file mode 100644 index 00000000..58290215 --- /dev/null +++ b/events/2016/Kubernetes_1st_Bday.md @@ -0,0 +1,23 @@ +# Kubernetes 1st Birthday Announcement + +Dear Kubernauts, + +Happy birthday! The Kubernetes community is celebrating the first anniversary for the v1.0 release on July 21st, 2016. We are reaching out to you as the chief point(s) of contact for your local Kubernetes meetup to encourage you to throw a Kubernetes birthday party! + +This is very exciting for the Kubernetes community, and we are happy to support your party planning efforts. We have swag we can provide (including awesome Kubernetes party hats!) and we will do our best to support your other endeavors. + +Since the actual anniversary is on July 21st, that date will likely be receiving the majority of the press and social media attention. But, by no means do you need to force your meetup to happen on July 21st; any time in late July or early August works great! We’re just hoping to get more people excited about Kubernetes and get users and developers meeting across the world. + +You may additionally be interested in joining the [Kubernetes Meetup leads mailing list](https://groups.google.com/forum/#!members/kubernetes-meetup-leads) where you can meet other organizers and swap tips. The [CNCF](https://cncf.io/community) is also working with Kubernetes meetups to offer support for things like Meetup.com fees and events, including financial support up to $250 for some official meetups. For more information on that effort, you can contact [Chris Aniszczyk](mailto:caniszczyk@linuxfoundation.org) and [Brett Preston](mailto:bpreston@linuxfoundation.org). + +Please contact us via [this Google form](https://docs.google.com/forms/d/1B17ckkz-FYEFhkQ2ZD8PZBH1ZnSCdpS366lB3a6MAtE/viewform) with any questions / requests / suggestions for your meetup. Alternatively, you can reach out to us directly (czahedi@google.com and sarahnovotny@google.com). We hope to hear from you soon! + +Lastly, if you know other people working with Kubernetes, please send this invitation their way! It could be a great chance for them to plug into a Meetup.com group or the mailing list above. + +And lest we forget, I’m Cameron Zahedi. I’ll be working with Sarah on her Kubernetes community endeavors, and I’m happy to help (or find the right person to help!) wherever possible. + +Cheers, + +Cameron and Sarah (on behalf of the Kubernetes Community.) + + diff --git a/events/2016/developer-summit-2016/KubDevSummitVoting.md b/events/2016/developer-summit-2016/KubDevSummitVoting.md new file mode 100644 index 00000000..46909c02 --- /dev/null +++ b/events/2016/developer-summit-2016/KubDevSummitVoting.md @@ -0,0 +1,33 @@ +###Kubernetes Developer's Summit Discussion Topics Voting +### +A voting poll for discussion topic proposals has been created, and the link to the poll can be found [here][poll]. + +The poll will close on 10/07/16 at 23:59:59 PDT. + +#### How Does it Work? +#### +The voting uses the Condorcet method, which relies on relative rankings to pick winners. You can read more about the Condorcet method and the voting service we're using on the [CIVS website][civs]. + +There are 27 topics to choose from, and you will rank them from 1 (favorite) to 27 (least favorite). You can also mark "no opinion" on topics that you don't wish to include in the ranking. + +The poll on CIVS has just the topic titles for ease of viewing. For topic descriptions, please see this [spreadsheet][topics]. The topic order on the voting service should mirror the order on the spreadsheet. + +You will note the message saying "*Only the 15 favorite choices will win the poll*". CIVS requires a number be selected for winners, and we have arbitrarily chosen 15. The final schedule may include more or less than 15 of the submitted topics. + +##### A Small Request +##### + +In order to make the poll accessible via URL, it has to be made "public". This means than any unique IP address can vote, which can be easily exploited for multiple votes. + +We fully expect the community to behave with sportsmanship and only vote once, and as such we almost didn't bring this concern up to begin with. However, we have chosen to explicitly address it, in order to reiterate the importance of everyone's voice receiving equal weight in a community-driven event. + +#### After the Poll +#### +A schedule will be made from the winning topics with +some editorial license, and the schedule will be announced to the group +at least a week before the event. + +[//]: # (Reference Links) + [civs]: + [poll]: + [topics]: \ No newline at end of file diff --git a/events/2016/developer-summit-2016/Kubernetes_Dev_Summit.md b/events/2016/developer-summit-2016/Kubernetes_Dev_Summit.md new file mode 100644 index 00000000..f66df508 --- /dev/null +++ b/events/2016/developer-summit-2016/Kubernetes_Dev_Summit.md @@ -0,0 +1,96 @@ +# Kubernetes Dev Summit +# + +## Edit - Event Location +## +The event is on the 4th Floor of the *Union Street Tower* of the Sheraton Seattle Hotel. + +# About the Event +# +The Kubernetes Developers' Summit provides an avenue for Kubernetes +developers to connect face to face and mindshare about future community +development and community governance endeavors. + +In some sense, the summit is a real-life extension of the community +meetings and SIG meetings. + +## Event Format +## +The Dev Summit is a "loosely-structured [unconference][uncf]". Rather +than speakers and presentations, we will have moderators/facilitators +and discussion topics, alongside all-day completely unstructured +hacking. + +The discussion sessions will be in an open fishbowl format — rings of +chairs, with inner rings driving the discussion — where anyone can +contribute. The various sessions will be proposed and voted on by the +community in the weeks leading up to the event. This allows the +community to motivate the events of the day without dedicating precious +day-of time to choosing the sessions and making a schedule. + +There will be 3 rooms dedicated to these sessions running in parallel +all day. Each session should last between 45 minutes and an hour. + +Then, there will be 2 smaller rooms for hacking / unstructured +discussion all day. + +#### Who Should Go? +#### +The target audience is the Kubernetes developer community. The group +will be relatively small (~120-150 attendees), to improve communication +and facilitate easier decision-making. The majority of the attendees +will be selected from key company team and SIG leaders, power-users, and +the most active contributors. An additional pool of tickets will be +awarded via lottery. **Any interested party** should enter the lottery via +[this form][lotfrm]. Invitees will receive an invitation on or before October 12th. +RSVP information will be available in the invitation email. Tickets are +not transferrable. + +Please note that this Summit is not the right environment for people to +*start* learning about the Kubernetes project. There are plenty of +[meetups][mtp] organized by global user groups where one can get +involved initially. + +#### Call for Proposals +#### +Proposals for discussion topics can be submitted through [this +form][propfrm] by September 30, 23:59 PT. If you propose a session topic, +please be prepared to attend and facilitate the session if it gets +chosen. Other members will help with moderating, either as volunteer +co-facilitators or as members of the larger discussion group. + +Suggestions for session topic themes: + +* Hashing out technical issues +* Long term component / SIG planning + +In early October, proposal topics will be posted to the kubernetes-dev +mailing list and voted on via [CIVS][civs], the Condorcet Internet +Voting Service. A schedule will be made from the winning topics with +some editorial license, and the schedule will be announced to the group +at least a week before the event. + +## When & Where? +## +The Dev Summit will follow [Kubecon][kbc] on November 10th, 2016. +Fortunately for those who attend Kubecon, the Dev Summit will be at the +same venue, [the Sheraton Seattle Hotel][sher]. As of now, the day's +activities should run from breakfast being served at 8 AM to closing +remarks ending around 3:30 PM, with an external happy hour to follow. + +## Desired outcomes +## +* Generate notes from the sessions to feed the project's documentation +and knowledge base, and also to keep non-attendees plugged in +* Make (and document) recommendations and decisions for the near-term and +mid-term future of the project +* Come up with upcoming action items, as well as leaders for those action items, for the various topics that we discuss + +[//]: # (Reference Links) + [uncf]: + [mtp]: + [lotfrm]: + [propfrm]: + [civs]: + [kbc]: + [sher]: diff --git a/events/2016/developer-summit-2016/application_service_definition_notes.md b/events/2016/developer-summit-2016/application_service_definition_notes.md new file mode 100644 index 00000000..e8f4c0c5 --- /dev/null +++ b/events/2016/developer-summit-2016/application_service_definition_notes.md @@ -0,0 +1,48 @@ +# Service/Application Definition + +We think we need to help out the developers in how do we organize our services and how do I define them nicely and deploy on our orchestrator of choice. Writing the Kube files is a steep learning curve. So can we have something which is a little bit easier? + +Helm solves one purpose for this. + +Helm contrib: one of the things folks as us is they start from a dockerfile, and they want to have a workflow where they go from dockerfile-->imagebuild-->registry-->resource def. + +There are different ways to package applications. There's the potential for a lot of fragmentation in multi-pod application definitions. Can we create standards here? + +We want to build and generate manifests with one tool. We want "fun in five" that is have it up and running in five minutes or less. + +Another issue is testing mode; currently production-quality Helm charts don't really work on minikube,. There's some issues around this which we know about. We need dummy PVCs, LoadBalancer, etc. Also DNS and Ingress. + +We need the 80% case, Fabric8 is a good example of this. We need a good set of boundary conditions so that the new definition doesn't get bigger than the Kube implementation. Affinity/placement is a good example of "other 20%". + +We also need to look at how to get developer feedback on this so that we're building what they need. Pradeepto did a comparison of Kompose vs. Docker Compose for simplicity/usability. + +One of the things we're discussing the Kompose API. We want to get rid of this and supply something which people can use directly with kuberntes. A bunch of shops only have developers. Someone asked though what's so complicated with Kube definitions. Have we identified what gives people trouble with this? We push too many concepts on developers too quickly. We want some high-level abstract types which represent the 95% use case. Then we could decompose these to the real types. + +What's the gap between compose files and the goal? As an example, say you want to run a webserver pod. You have to deal with ingress, and service, and replication controller, and a bunch of other things. What's the equivalent of "docker run" which is easy to get. The critical thing is how fast you can learn it. + +We also need to have reversability so that if you use compose you don't have to edit the kube config after deployment, you can still use the simple concepts. The context of the chart needs to not be lost. + +There was discussion of templating applications. Person argued that it's really a type system. Erin suggested that it's more like a personal template, like the car seat configuration. + +There's a need to let developers work on "their machine" using the same spec. Looking through docker-compose, it's about what developers want, not what kubernetes wants. This needs to focus on what developers know, not the kube objects. + +Someone argued that if we use deployments it's really not that complex. We probably use too much complexity in our examples. But if we want to do better than docker-compose, what does it look like? Having difficulty imagining what that is. + +Maybe the best approach is to create a list of what we need for "what is my app" and compare it with current deployment files. + +There was a lot of discussion of what this looks like. + +Is this different from what the PAASes already do? It's not that different, we want something to work with core kubernetes, and also PAASes are opinionated in different ways. + +Being able to view an application as a single unifying concept is a major desire. Want to click "my app" and see all of the objects associated with it. It would be an overlay on top of Kubernetes, not something in core. + +One pending feature is that you can't look up different types of controllers in the API, that's going to be fixed. Another one is that we can't trace the dependencies; helm doesn't label all of the components deployed with the app. + +Need to identify things which are missing in core kubernetes, if there are any. + +## Action Items: + +* Reduce the verbosity of injecting configmaps. We want to simplify the main kubernetes API. For example, there should be a way to map all variables to ENV as one statement. +* Document where things are hard to understand with deployments. +* Document where things don't work with minikube and deployments. +* Document what's the path from minecraft.jar to running it on a kubernetes cluster? diff --git a/events/2016/developer-summit-2016/cluster_federation_notes.md b/events/2016/developer-summit-2016/cluster_federation_notes.md new file mode 100644 index 00000000..362cbafe --- /dev/null +++ b/events/2016/developer-summit-2016/cluster_federation_notes.md @@ -0,0 +1,21 @@ +# Cluster Federation + +There's a whole bunch of reasons why federation is interesting. There's HA, there's geographic locality, there's just managing very large clusters. Use cases: + +* HA +* Hybrid Cloud +* Geo/latency +* Scalability (many large clusters instead of one gigantic one) +* visibility of multiple clusters + +You don't actually need federation for geo-location now, but it helps. The mental model for this is kind of like Amazon AZ or Google zones. Sometimes we don't care where a resource is but sometimes we do. Sometimes you want specific policy control, like regulatory constraints about what can run where. + +From the enterprise point of view, central IT is in control and knowledge of where stuff gets deployed. Bob thinks it would be a very bad idea for us to try to solve complex policy ideas and enable them, it's a tar pit. We should just have the primitives of having different regions and be able to say what goes where. + +Currently, you either do node labelling which ends up being complex and dependent on discipline. Or you have different clusters and you don't have common namespaces. Some discussion of Intel proposal for cluster metadata. + +Bob's mental model is AWS regions and AZs. For example, if we're building a big cassandra cluster, and you want to make sure that nodes aren't all in the same zone. + +Quinton went over a WIP implementation for applying policies, with a tool which applies policy before resource requests go to the scheduler. It uses an open-source policy language, and labels on the request. + +Notes interrupted here, hopefully other members will fill in. diff --git a/events/2016/developer-summit-2016/cluster_lifecycle_notes.md b/events/2016/developer-summit-2016/cluster_lifecycle_notes.md new file mode 100644 index 00000000..f42df9f6 --- /dev/null +++ b/events/2016/developer-summit-2016/cluster_lifecycle_notes.md @@ -0,0 +1,132 @@ +# Cluster Lifecycle Deployment & Upgrade Roadmap + +Moderator: Mike Danese + +Note taker: Robert Bailey + +Date: 2016-11-10 + +## Goals + +Discuss HA, upgrades, and config management beyond kubeadm/kops & try to identify things that are currently underserved (upgrade testing, version skew policy, security upgrades) + +## Discussion + +kubeadm - not destined for production? +* Doing resource provisioning (cloud VMs) is out of scope +* Should be a toolbox that does the common parts of cluster lifecycle + * And should be able to break out just the pieces that you want +* Found a bunch of common parts of existing cluster deployment and want to build more of it into the core + +AI (luke): Create an intro guide to cluster lifecyle + +If anyone wants to work on Upgrades the Hard Way with Rob this afternoon. + +Wishlist +* HA +* Upgrades +* Config Management +* Toolbox vs. guided flow +* Documentation +* Conformance Testing +* PKI + +### HA + +* Story hasn't changed in a long time: + * People set up the cluster, run them in production + * Lack of documentation +* What haven't we been focused on? + * Some day there may be apiservers that may move, but there aren't today + * If you've misconfigure it, it's really hard to debug + * E.g. If you just launch 2 apiservers they fight over the endpoint. It requires insider knowledge to recognize this and know how to fix it + * Forces an ip address on the endpoint, which isn't compatible with AWS + * AI (claytonc): Fix the flag to take a host instead of just an ip address +* There are things that are command line flags that are going to be a pain to synchronize + * Move more configuration into etcd + +### Upgrades + +* Minor and patch upgrades, look at them separately +* Do we have skew requirements that are different for minor vs patch upgrades? + * E.g. Can you upgrade nodes before master for a patch version? +* AI: Socialize the existing version skew documentation +* AI: Clarify the documentation skew +* Do we want to support 4-part version numbers? + * Chris love: please don't do this +* Mike Rubin: Patch releases shouldn't create surprises +* Distribution of Kubernetes? +* Jordan Liggitt: Would like to see upgrade documentation on every install guide + * At least for patch releases + * AI (?): File issues against owners for the current getting started guides to add a section on upgrades +* Luke Marsden: I would like to lead an effort to support self hosting in some of the user flows (in particular a kubeadm flow) in an attempt to make it really easy to deploy a patch upgrade + * Assume single master, external etcd + * Joe Beda: The nice thing about self hosting upgrades is that there isn't anything cloud platform specific which allows us to build more general tooling + +### Distribution + +* In 1.5 we've begun experimenting with OS package management tooling +* Should we push further on this? +* The release tarball is getting bigger + * Should be ameliorated in 1.5 by breaking it into arch-specific bundles +* Jordan Liggitt: We can't tell people to script their install against the tarball because the structure of the tarball becomes an api + +### Config Management + +* Config is currently command line flags. Work is being done to convert into structured api types (outstanding PRs from ncdc@ and mtoffen@). +* How much should we use config maps vs flags vs something else? +* Joe Beda: Definitely an issue for the kubelet - specifically setting the DNS IP flag + * Vish: Unless/until the kubelet has local checkpointing it's dangerous to use the apiserver for checkpointing configuration since the apiserver may become unavailable +* Need to figure out how we deal with config that points to other files (e.g. certs) +* Rob: We may want to split the discussion about configuring the kubelet vs the control plane +* Mike Rubin: The kubelet will eventually need to be able to run standalone. Need to think about packaging and configuration as distinct. + * The Kubelet has a lot of value if it can work without an apiserver + * The node effort takes Docker + Linux and productizes it +* Mike Danese: The same type of config could also benefit other components +* Jordan Liggitt: Have client cert bootstrap stuff in Kubelet + +### Toolbox vs guided flow + +* [mostly skipped for time] +* Chris Love: Need to document our compartmentelizing each thing +* Luke: This isn't a "vs" it's an "and" + +### Documentation + +* What is lacking? +* Joe Beda: The fact that Kelsey had to write "Kubernetes the hard way" shows that we don't have documentation +* Chris Love: HA Upgrades +* Jordan Liggitt: Docs should look like a tree + * Start at the high level, if you want more detail, then you can drill down into each piece + * If you expand to all of the leaves, then you end up back at k8s the hard way +* Mike Rubin: Questions from support/users are less about setting up and more about tearing down + * What will still be around after destroying a cluster + * E.g. Deleting a namespace, deleting a cluster from a federation, deleting a node from the cluster +* Need an introduction to the SIG (Luke already volunteered to write one) +* Mike Rubin: Rollbacks and rollback documentation + * When you add a new feature (say in 1.4) and we roll back to an earlier version what happens to those resources + * Chris Love: elephant is what happens when you roll back from etcd3 → etcd2 + +### Conformance Testing + +* What can we do in 2017 to make progress on this? +* Jordan Liggitt: Need to categorize conformance tests into ones that you could run against a production cluster vs those that you shouldn't +* Lucas: Three levels of validation: node, k8s standard base, deep/destructive testing. Want to make these all easy through kubeadm +* Is performance testing out of scope? + * Clayton: Misconfiguration is often caught through performance testing so we shouldn't remove it from scope + +### PKI + +* Jordan Liggitt: Have client cert bootstrap stuff in Kubelet +* Chris Love: Need to loop in sig-auth. Need to use TLS certs for etcd clusters. +* Aaron Levy: Plan to add CSR into the etcd operation similar to what is going into the k8s api. +* Joe Beda: Two modes right now: can have the apiserver act as a CA; many serious users will want to use their own CA +* Jordan Liggitt: Things that need certs should be able to take them or components should be able to generate (if appropriate) + * Rotation depends on whether we are using the built-in CA or an external CA +* Mike Rubin: Why not do both rotation and revocation + * Rob: Many applications don't respect revocation so it's generally considered weaker +* Clayton: If you can rotate then you may not need to revoke +* Jordan Liggitt: Tied to config management +* Joe Beda: Part of the discovery info is the root CA and many people don't realize that it can be a bundle instead of a single CA — this enables rotation +* Clayton: In a secured cluster, etcd is the core. Have to think about it as the inner circle of security that the apiserver is outside of. If you are extremely cautious then you should use client certs in the apiserver. You can collapse the rings if you want. + diff --git a/events/2016/developer-summit-2016/k8sDevSummitSchedule.pdf b/events/2016/developer-summit-2016/k8sDevSummitSchedule.pdf new file mode 100644 index 00000000..6cd8d01b Binary files /dev/null and b/events/2016/developer-summit-2016/k8sDevSummitSchedule.pdf differ diff --git a/events/2016/developer-summit-2016/statefulset_notes.md b/events/2016/developer-summit-2016/statefulset_notes.md new file mode 100644 index 00000000..d019d256 --- /dev/null +++ b/events/2016/developer-summit-2016/statefulset_notes.md @@ -0,0 +1,38 @@ +# StatefulSets Session + +Topics to talk about: +* local volumes +* requests for the storage sig +* reclaim policies +* Filtering APIs for scheduler +* Data locality +* State of the StateFulSet +* Portable IPs +* Sticky Regions +* Renaming Pods + +## State of the StatefulSet + +1.5 will come out soon, we'll go beta for StatefulSets in that one. One of the questions is what are the next steps for Statefulsets? One thing is a long beta, so that we know we can trust statefulsets and they're safe. + +Missed some discussion here about force deletion. + +The pod isn't done until the kubelet says it's done. The issue is what happens when we have a netsplit, because the master doesn't know what's happening with the pods. In the future we'll maybe add some kind of fencer to make sure that they can't rejoin. Fencing is probably a topic for the Bare-Metal Sig. + +Are we going to sacrifice availability for consistency? We won't explicitly take actions which aren't safe automatically. Question: should the kubelet delete automatically if it can't contact the master? No, because it can't contact the master to say it did it. + +When are we going to finish the rename from PetSet to StatefulSet? The PR is merged for renaming, but the documentation changes aren't. + +Storage provisioning? The assumption is that you will be able to preallocate a lot of storage for dynamic storage so that you can stamp out PVCs. If dynamic volumes aren't simple to use this is a lot more annoying. + +Building initial quorums issue? + +It would be great to have a developer storage class which ties back to a fake NFS. For testing and dev. The idea behind local volumes is that it should be easy to create throwaway storage on local disk. So that you can write things which run on every kube cluster. + +Will there be a API for the application? To communicate members joining and leaving. Answer today is that's what the KubeAPI is for. + +The hard problem is configchange. You can't do config change unless you bootstrap it correctly. If kube is changing things under me I can't maintant quorum (as an app). This happens when expanding the set of nodes. You need to figure out who's in and who's out. + +Where does the glue software which relates the statefulset to the application? But different applications handle things like consensus and quorum very differently. What about notifying the service that you're available for traffic. Example for this with etcd with readiness vs. membership service. You can have two states, one where the node is ready, and one where the application is ready. Readiness vs. liveness check could differentiate? + +Is rapid spin-up a real issue? Nobody thinks so, diff --git a/events/2016/fixit201606.md b/events/2016/fixit201606.md new file mode 100644 index 00000000..f7d43641 --- /dev/null +++ b/events/2016/fixit201606.md @@ -0,0 +1,61 @@ +#Fixit Event June 2016 + +Google runs internal fixit weeks. During these weeks the teams set aside all critical deadlines, showstopper bugs, regular development -- everything -- to pull together to achieve a common goal. And, we invite the Kubernetes community to join the June 2016 fixit. + +Please take a look at anything that is [kind/flake] (https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Akind%2Fflake%20) or, with our 1.4 focus on "mean time to dopamine" for our users, help [team/ux] (https://github.com/kubernetes/kubernetes/labels/team%2Fux) or spend time triaging, de-duplicating, or closing issues that were [opened before 20160101] (https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=created%3A%3C2016-01-01%20state%3Aopen%20) or check out the [issues in our docs] (https://github.com/kubernetes/kubernetes.github.io/issues) repository. All of these avenues will help Kubernetes improve the user and developer experiences with the project. + +Another important piece of fixit culture is rewards. **Everyone who contributes (as measured by engagements on Github) between 6/27 and 7/1 will receive Kubernetes stickers and all merged PRs that are contributed during the fixit will will receive a Kubernetes embroidered patch.** + +#But, wait, there's more! + +Since improvement isn't only about code and issues, we'd like to also help grow our community skills. And, to that end, below is a schedule of some interesting content and community events. + +The community meeting calendar is [available as an iCal] +(https://calendar.google.com/calendar/ical/cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com/public/basic.ics) +to subscribe to (simply copy and paste the url into any calendar +product that supports the iCal format) or [html to view] +(https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). +All sessions listed below are listed on the community calendar and +will be broadcast on the [community meeting URL] +(https://zoom.us/my/kubernetescommunity). + +##Tuesday 05:00 PT + +**Office Hours - Filip Grzadkowski [Recording] (https://www.youtube.com/watch?v=nKHYnvTr7LE)** + +K8s developers to hold office hours over VC where we ask members of the community to bring questions about how the system works. + +##Thursday 10:00 PT + +**Community Meeting - Usual Suspects [Recording] (https://www.youtube.com/watch?v=gv3yMQ_F4_k)** + +The usual get together full of demos, discussions, and yummy yummy information. + +##Thursday 11:00 PT + +**Office Hours - Vishnu Kannan [Recording] (https://www.youtube.com/watch?v=v_WI4P1ZEEQ)** + +K8s developers to hold office hours over VC where we ask members of the community to bring questions about how the system works. + +##Friday 10:00 PT + +**1.3 Release Community Postmortem - Jason Singer Dumars [Recording] (https://youtu.be/kqKW7QLlwAA)** + +Following the release of 1.3 this is an opportunity to share what went well, what went poorly and discuss how we want to improve the development and release of 1.4. + +##To be rescheduled. + +**A live debugging session. -- Janet Kuo** + +It's possible to learn so much while watching others debug. One of our team members will debug a problem during a video session. They will show the community tricks and informal techniques required to solve problems live. + +#Metrics + +For those of you who are tracking our progress... + +[Issues and PRs closed >2016-06-27] (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+closed%3A%3E2016-06-27+&type=Issues&ref=searchresults) + +[Issues created and still open >2016-06-27] (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+created%3A%3E2016-06-27+is%3Aopen&type=Issues&ref=searchresults) + +Alternately, [counting only closed issues] (https://github.com/search?utf8=%E2%9C%93&q=org%3Akubernetes+closed%3A%3E2016-06-27+is%3Aissue&type=Issues&ref=searchresults) + diff --git a/events/2017/05-leadership-summit/announcement.md b/events/2017/05-leadership-summit/announcement.md new file mode 100644 index 00000000..4417a910 --- /dev/null +++ b/events/2017/05-leadership-summit/announcement.md @@ -0,0 +1,26 @@ +This is an announcement for the 2017 Kubernetes Leadership Summit, which will occur on June 2nd, 2017 in San Jose, CA. +This event will be similar to the [Kubernetes Developer's Summit](/community/2016-events/developer-summit-2016/Kubernetes_Dev_Summit.md) in November +2016, but involving a smaller smaller audience comprised solely of leaders and influencers of the community. These leaders and +influences include the SIG leads, release managers, and representatives from several companies, including (but not limited to) +Google, Red Hat, CoreOS, WeaveWorks, Deis, and Mirantis. + +The summit will provide an avenue for leaders in the Kubernetes community to connect face to face and mindshare about future +community development and community governance endeavors. + +This announcement serves to notify the broader community of the existence and goals of the event. + +This is an **invite-only event**. All invitees will receive a direct invitation from Cameron (czahedi *at* google *dot* com). + +### Event Format + +The Leadership Summit will mirror the format of the Developer’s Summit, which was a "loosely-structured unconference”. We will have moderators/facilitators and discussion topics, alongside all-day completely unstructured / spontaneous breakouts. + +The various sessions will be proposed and voted on by the community in the weeks leading up to the event. This allows the +community to motivate the events of the day without dedicating precious day-of time to choosing the sessions and making a +schedule. + +### Desired outcomes + +* Generate notes from the sessions to feed the project's documentation and knowledge base, and also to keep non-attendees plugged in +* Make (and document) recommendations and decisions for the near-term and mid-term future of the project +* Come up with upcoming action items, as well as leaders for those action items, for the various topics that we discuss diff --git a/events/2017/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md b/events/2017/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md new file mode 100644 index 00000000..a6fa64de --- /dev/null +++ b/events/2017/05-leadership-summit/session-notes/0300-0345_CODEORGANIZATION.md @@ -0,0 +1,198 @@ +# Code Organization and Release Process Improvement + +**Identify the following before beginning your session. Do note move forward until these are decided / assigned: ** + +- **Session Topic**: Code Organization and Release Process Improvement +- **Topic Facilitator(s)**: bgrant0607@ +- **Note-taker(s) (Collaborating on this doc)**: jdumars@ +- **Person responsible for converting to Markdown & uploading to Github:** michellen@ + +### Session Notes + +#### Background from November dev summit: +- [Slides](https://docs.google.com/presentation/d/1SD6a6eJl47t0qyTFE8GzaiytW4T_crdWgYAMCaLy1W8/edit#slide=id.g18ae10430d_0_7) +- [Notes](https://www.google.com/url?q=https://docs.google.com/document/d/1zN2DWKerXwbzxZTO52wBRqp_uHMdLp8P52xYOmp5WZ4/edit&sa=D&ust=1496186064062000&usg=AFQjCNG8Z-9KBJJkUsQY9F38CdZY3Nc_LA) + +#### Github orgs: +Github supports 2 levels of hierarchy, orgs and repos, and we need to use both effectively. We need to move away from monorepos, such as kubernetes/kubernetes and kubernetes/contrib, and mono-orgs, such as kubernetes and kubernetes-incubator. [Kubernetes-client](https://github.com/kubernetes-client) is the first focused org. + +Ideally, code would be divided along lines of ownership, by SIG and subproject, with infrastructure for packaging the code (APIs and controllers) into the desired number of components (e.g., hyperkube as well as factored by [layer](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.p)) and releases (e.g., [monthly](https://github.com/kubernetes/community/issues/567) as well as LTS). + + +#### Where we are on multiple repos: +* [Code organization issue](https://github.com/kubernetes/kubernetes/issues/4851) +* [kubernetes multi-repo issue](https://github.com/kubernetes/kubernetes/issues/24343) and [contrib](https://github.com/kubernetes/contrib/issues/762) breakup issue +* User docs were moved to kubernetes/kubernetes.github.io +* Contributor docs were moved to kubernetes/community +* Examples have been copied to kubernetes/examples, but haven’t yet been removed from the kubernetes repo +* [API machinery](https://github.com/kubernetes/kubernetes/issues/2742): In order to build virtually anything outside the kubernetes repo, the API machinery needs to be made available, for component configuration, for building APIs, for building controllers and other Go clients of the APIs, etc. + * Staging + * [Client-go](https://github.com/kubernetes/kubernetes/issues/41629) + * [API types](https://github.com/kubernetes/kubernetes/pull/44784), will be done during 1.7 code freeze +* TODO: util + * pkg/util moves thread +* Kubectl: + * In the process of breaking kubectl <-> kubernetes dependencies + * Have kubernetes/kubectl repo, need to migrate issues there + * Issue migration tool exists - creates lots of notifications + +Next up: +* [kubeadm](https://github.com/kubernetes/kubernetes/issues/35314) +* Federation +* [cloudprovider](https://git.k8s.io/kubernetes/pkg/cloudprovider/README.md) and [cluster](https://git.k8s.io/kubernetes/cluster/README.md) +* Scheduler +* [Kubelet](https://github.com/kubernetes/kubernetes/issues/444) + +#### Build system and checking in generated code (or not): +* [Issue about not checking in generated code](https://github.com/kubernetes/kubernetes/issues/8830) +* [Nuke Ugorji](https://github.com/kubernetes/kubernetes/issues/36120) +* [Update and verify script thread](https://groups.google.com/d/msg/kubernetes-dev/5rVmSJqCq-U/tyN8OVRjBgAJ) +TODO: Bazel, make + +#### Vendoring: +What would be better than godeps? Dep? Glide? +[https://github.com/kubernetes/kubernetes/issues/44873](https://github.com/kubernetes/kubernetes/issues/44873) + +#### Other: +* Client and [client tool](https://github.com/kubernetes/release/issues/3) releases +* More unit tests rather than end-to-end tests +* [Feature branches](https://github.com/kubernetes/community/issues/566) + +#### Multi-repo requirements + +#### Release process +* Components are combined from subrepos to build released bits +* Components each have sufficient testing against their repo to determine if they are stable to release + +#### Development process in multiple repos +* PRs sent to external repos +* PR and CI tests run against external repo. Sufficient to validate the code maybe released as a component. + * Unit + Integration tests + * e2e tests? +* Automatically update vendored deps from consuming repos +* e2e tests run against main repo against integrated components + +#### Process to move code into its own repo + +#### Considerations +* Does the code depend on kubernetes/kubernetes code? + * Break these dependencies or move the deps to another repo +* Does other code from kubernetes/kubernetes depend on the code? + * Must update package names +* Can code be fully tested independent of kubernetes/kubernetes code? +* Will the code share the same release as kubernetes/kubernetes or be released independently? + * Clients released independently need a way to perform version skew testing + +#### Possible workflow +* Maybe first move to “staging” directory to simulate multi-repo within single repo - this has its own costs +* Remove cyclic dependencies between repositories +* Update mungebot to close PRs that update moved packages +* Copy code to new location +* Vendor code from new location to main repo (if needed) +* Change package names to the vendored code +* Delete old code + +Where do we need to get to in order to separate: [ [diagram](https://files.slack.com/files-tmb/T09NY5SBT-F5NU1FPPG-0bb64d7351/image_uploaded_from_ios_1024.jpg) ] +* Utility packages need to go somewhere +* API packages need to move +* Helper libraries (reusable server infrastructure) +* Code generators + +Consumer-visible +* client go +* kubectl + +Need to get the API types into their own repo +* currently have a staging area, and a copy/paste script +Need to develop in those repos and then assemble a coherent release from them + +re: kubectl moving, +* 1. sits in the repo but build rules break bad dependencies, can start shipping it independently +* 2. make sure everything still works + +kubectl could get its own release + +build files to add visibility + +kubectl should never be imported + +As these refactors happen, Brian Grant will be more lenient with privileges, establishing janitors + +kubectl split is technical debt cleanup - testing should not rely on e2e, no compiled-in dependencies + +breaking the dependencies yields more benefits + +Q: Will kubectl be buildable with go get? +A: Probably, but definitely with bazel + +Integration testing plan? +Use last stable release in k/k e2e tests + +We need to catch regressions when it’s being released, not when it’s vendored back in + +Need better, smaller tests overall + +kops has a blocking PR test - kops master + what is in your PR + +cross-component problems at the main level + +Need a central build pipe in order to untangle dependencies + +Experience breaking apart has been negative as a contributor + +Q: What is the contribx? Testing? +A: Short term will be many separate PRs, need to solve dependencies in test management + +Please do not add new binaries in the kubernetes repo + +Need help +* getting rid of generated code +* build system +* solve vendoring problem + +Working group? Code health WG + +Client tool SDK? + +kubectl -> SIG CLI +code -> API Machinery + +Caution against validating undocumented functionality via CI, better: documentation and integration test as a validation ~ API testing + +Too much testing is currently e2e + +Don’t make a catchall util package + +### Conclusions + +#### Key Takeaways / Analysis of Situation +#### Recommendations & Decisions Moving Forward (High-Level) + +Should build and release be the same SIG? Where does build live? -- SIG release / SIG testing + +Q: Is it worthwhile to go through the project and specify what needs to be moved out? +A: In the SIG assignment process there may be breakup + + +Action Item |Owner(s) +------------|------------ +Need a SIG owner on utilities | Tim Hockin +Talk to Cloud Foundry and see how they do it | Caleb at Community +Working group organization or a SIG that oversees this | Machinery, CLI, Cluster Lifecycle +Regular community checkins | Brian Grant +Describe the end state and then assign breakout work to SIGs | Working group needs to be organized - Brian Grant + +#### Instructions +1. Make a copy of the “Template” area of this document in the folder. +2. Set the “Share” settings to be “anyone with the link can edit” and take your session notes there. Ensure to decide/assign (and document) the topic title, facilitator(s), note-taker(s), and Github uploader. +3. Later, convert the notes to Markdown and upload to this GitHub directory: +4. Save your session notes with the following format: + a. HHMM-HHMM_SESSIONTITLE.md + i. where HHMM is the time in 24-hour format in the PST zone. + + +#### Suggestions +* Use the document outline (Tools > Document Outline) and headings (Format > Paragraph Styles) to organize your notes as you go + + +[Link to original doc](https://docs.google.com/document/d/163JvzDIuBa4CzttxxG8tjYYPACQnD1DboW3BDG8VCUA/) diff --git a/events/2017/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md b/events/2017/05-leadership-summit/session-notes/0905-0930_STATE_OF_THE_KUBE.md new file mode 100644 index 00000000..05287aad --- /dev/null +++ b/events/2017/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/events/2017/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md b/events/2017/05-leadership-summit/session-notes/0940-1000_PROJECT_GOALS_ROADMAP.md new file mode 100644 index 00000000..453b3931 --- /dev/null +++ b/events/2017/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/events/2017/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md b/events/2017/05-leadership-summit/session-notes/1015-1115_UPDATES_GOVERNANCE_AND_CNCF.md new file mode 100644 index 00000000..7e49baa8 --- /dev/null +++ b/events/2017/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/events/2017/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md b/events/2017/05-leadership-summit/session-notes/1145_1245_ARCHITECTURAL_ROADMAP.md new file mode 100644 index 00000000..8349c40d --- /dev/null +++ b/events/2017/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#) diff --git a/events/2017/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md b/events/2017/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md new file mode 100755 index 00000000..397c7c6a --- /dev/null +++ b/events/2017/05-leadership-summit/session-notes/1345-1430_SIGGOVERNANCE.md @@ -0,0 +1,107 @@ +# SIG Governance and Check-in + +**Identify the following before beginning your session. Do not move forward until these are decided / assigned:** + +- **Session Topic: SIG Governance and check-in** +- **Topic Facilitator(s):** brendandburns@ +- **Note-taker(s) (Collaborating on this doc)**: jbeda@ +- **Person responsible for converting to Markdown & uploading to Github:** philips@ + +### Session Notes + +- Core discussions about SIG leadership + - Is the SIG lead role more like an on-call position or a team lead? + - There are 2 parts of the role: facilitation and management of the owners files + - authority comes from commits? + +#### Conclusions + +#### Key Takeaways / Analysis of Situation + +Recommendations & Decisions Moving Forward (High-Level) + +Specific Action Items (& Owners) + +| **Action Item** | **Owner(s)** | +| --- | --- | +| SIG starter kit: Gather constructive feedback from SIGs; Create a summary of that feedback | Bob Wise | +| How should SIG lead/governance work? Figure out a lot of this stuff. Everyone should share with the steering committee and get that ready for the full committee. | Steering Committee | +| Schedule SIG lead office hours to coordinate around PRs and getting stuff done. | Jason DuMars | +| SIG-architecture? | Steering Committee | +| SIG consolidation? | Steering Committee | + +#### Purpose + +- Michelle + - What is your format? + - How is it going? + - Are there things that you are struggling with? + - Do we need to formalize about forming/running/governing a SIG? +- Joe + - How do we pick SIG leads? What type of leadership? What are the responsibilities? Is this the same across the project or per SIG? + +#### Discussion + +- Rob: Cross cutting sig concerns? Venn diagram? Common concerns get lost. SIG-cloud is similar. +- What other types of horizontal/project? + - Ops, testing, etc. +- Bob: Would it be useful to draw connection map and formalize communication channels +- Eric: Staff and line position? Line = line of business. Staff = centralized responsibility. + - Q: Where would you put SIG-testing? A: staff? Testing guidance for all the SIGs. + - Technical area (LoB) vs. staff (shared service and expertise) +- Brendan -- there are technical staff groups vs. non-technical staff groups. Example testing vs. contrib-x. +- Joe: without some sort of automated mechanism that forces people to communicate it won't happen. Perhaps having the SIGs own code will force discussions at time of PR +- If we have a forcing function there requires more planning up front. Example is the rush to a release. +- Scrum of scrums? Have the leads get together and hash over that. + - Focus on visibility with accountability. +- Luke: perhaps have sig leads do offline sync ups? Bring in others as necessary. + - Vish: Sig leads may not know what is going on. + - Quinton: have identified people in the SIG that owns relationship with specific other SIGs. +- Bob: Getting better definition of what the sig lead job is would help. + - Make SIG-PM be made up of SIG-leads + - Brendan: SIG lead should be a thankless position. Very little power. Should be obligation. Somewhat like an on-call rotation vs. TL. +- Quinton: Is there a TL position? Who is driving the overall technical direction of an area. Separate from the lead position. + - Brendan: SIGs own directories. Approvers in those directories are TLs. + - Bob: current model SIG leads are volunteer thing and so it is optimistic to expect too much. Do we want to have elections. + - Brendan: worry about gaming with the openstack model wrt elections. + - Rob: in OpenStack -- SIGs were project groups. The usage of SIG to mean project is confusing. + - Eric: If people are going to be SIG leads -- too much power for too much responsibility. Should we solve by adding responsibility. + - Do sig leads have power now? It is mostly influence? + - **** Code vs. talk. + - Bob: You can say "code talks" but getting code in and earning that position can be super frustrating. "Code == influence" just isn't true right now. + - Adding code is easy. Reviewing code, curating tests, etc. That is the hard thing. +- What are the expectations to put on a SIG. Keep track of issue response times? +- Jason: What is the job of SIGs? How do we identify that and make sure it gets done? There isn't that one thing to test against. + - Leadership follows from this mission. + - Eric: As a governing board do we care how a sig does it as long as it does it well? I think the answer is we don't care. Doubts around template. + - Luke: That seems fine -- but we need to share what works and what goes poorly. + - Brendan: others said cross sig stuff is hard. Also poor communication across dependencies. + - What is success? Depends on the SIG. Lay out a plan and then accomplish it. + - SIG have obligations to release and own thing. Example is tests for that thing. Need to define interfaces +- Michelle: what are the best processes for governing and monitoring a SIG. What are the best processes? +- Aaron: Qs: Do SIG updates and recording help with communication. +- Joe: What we discussed through bootstrap is that we should have a starter kit for the SIGs; we don't really have strong opinions on how it actually works in practice though. +- Dalton: Clear lines of ownership for SIGs would be appreciated. Would welcome more guidance. SIG on-prem struggles with what they are responsible for today +- Challenge for horizontal SIGs include membership (especially technical) and influence. +- Brendan: focus on fewer larger SIGs. Not enough people with smaller SIGs. Consolidation may make things more efficient. +- Aaron: SIG updates at community seem to help tell what the SIGs are focusing on but it doesn't help on a week to week or release wide process. + - Does SIG-PM coordinate a snapshot of what is going on. But it isn't enough communication. + - Ihor: Almost meeting have reports from SIGs. +- How do we push people to write code in the right direction. What tools do we have to guide things. + - Hope from the steering committee is that if SIGs aren't doing something they should be doing there is an escalation. Example is SIG-testing is empowered to stop queue until things change. +- Joe: Eng reviews/SIG-architecture + - Advise to who and where to get sign off. + - Bob: alleviate frustrations that we had + +Lots of discussions on how to drive communication and when things get escalated. Help SIGs coordinate between themselves. + +Up to steering committee to help define what the requirements are on a SIG. Still unsure what that'll look like. + +Jason: rename SIG-lead to SIG-facilitator + +Good Practices + +Kind of like a starter kit for SIGs? Needed and recommended? + +- Notes and videos help +- Focusing bi-weekly for PRs vs. design discussion. diff --git a/events/2017/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md b/events/2017/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md new file mode 100644 index 00000000..865d4999 --- /dev/null +++ b/events/2017/05-leadership-summit/session-notes/1500-1545_COMMUNITY_LADDER.md @@ -0,0 +1,75 @@ +# Community Building & Ladder Session + +_Original Title: “Building community effectiveness (Contributor ladder, Code of Conduct & Committee)”_ + +* Session Area: Community +* Topic Facilitator(s): Sarah Novotny +* Note-taker(s) (Collaborating on this doc): + * Rob Hirschfeld @zehicle + * Jess Frazzelle +* Person responsible for converting to Markdown & uploading to Github: Rob Hirschfeld @zehicle + +## Session Notes + +Classes of Communities being discussed: +* Developer / User - using the API +* Developer / Operator - running the Infrastructure / DevOps +* Developer / Contributor - writing the Kubernetes code, docs, any sort of non-technical contribution + +Topics/Conversation Thread: + +* Luke: How to get more people writing code in a sig, encourage new contributors to start contributing + * How sig leads can do a better job of encouraging contributors + * Defining contributions outside of code, people who plan face to faces, things that help build the community but are not necessarily limited to code +* Bob: contrib was declared dead, but if you are doing dev work in the community it is not clear where to put ideas out there for feedback + * Incubation bar is super high + * Things bigger than features, tools, etc +* Michael: talking about getting people involved without creating schedule risk + * There is a spreadsheet that people are using to track priorities of tasks + * Need to watch Shepherding bandwidth +* Sarah suggested that we need to make sure that reviewers are tagged as mentors also + * Helps people know who to ask for help, so they don’t stall +* Kris: it helps to get people to self-identify people’s interests in contributing +* Michael: use SIG meetings for status and encourage people to connect outside of meetings +* Jess: Suggested making sure to bring people in with an open item + * It helps to make introductions at the start of the meeting +* Kris - Bob: Office hours? Alternate weeks for the SIG +* Michael: Make sure to create a safe space - admit mistakes to be more inclusive +* Luke: there are a lot of people who are listening but not taking on work + +_Group discussed ways to get people to move into activity contributors_ + +* Sarah: hiring Community Manager role - first job will be to create a mentor pairing program +* Michael: challenge is that companies want their people to be counted as contributors. + * Discussion: this results in gamification and people not being able to participate + * There’s some organization learning + * We need to be aware of the conflicts +* Rob brought up that there are people entering the community who are not doing things that capture work that’s passive or just using + * Bob described a similar issue w/ Scale where the value is creating data and running tests +* Contributor ladder needs to include people who are using / operating without making code or docs contributions. We want to capture their experience and welcome +* Jess - could even use twitter activity and collect survey results +* Rob - it can be a very good thing to have a large passive audience + * Sarah - as long as there is enough people doing contribution + * Rob suggested that we may want user/operator SIGs that act as onboarding and then direct people to more specific SIGs + +## Conclusions +Key Takeaways / Analysis of Situation + +* SIGs have a lot of passive participants. - **This may be OK** +* We discussed ways to get passive users more engaged including + * introductions at start of meetings + * mentor pairings for new + * asking them about area of interest + * Pairing people for out-of-meeting 1x1 based on time zones + * Keep SIG meeting as status and drive out-of-meeting action +* There is a problem when companies reward people only on contributions of specific types or projects + +## Recommendations & Decisions Moving Forward (High-Level) + +* Create a User SIG for onboarding new users and directing them into other SIGs. This would effectively be an ongoing 101 +* Restart Cluster Ops SIG storytelling for operators and write them down +* SIGs to use off-weeks for office hours + +## Specific Action Items (& Owners) + +None Taken diff --git a/events/2017/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md b/events/2017/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md new file mode 100644 index 00000000..fa52f1dc --- /dev/null +++ b/events/2017/05-leadership-summit/session-notes/1600-1740_PRESENTATIONS_FROM_BREAKOUTS_AND_CALL_TO_ACTIONS.md @@ -0,0 +1,146 @@ +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)**: sarahnovotny@ +- **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) diff --git a/events/2017/05-leadership-summit/session-notes/readme.md b/events/2017/05-leadership-summit/session-notes/readme.md new file mode 100644 index 00000000..c7d61f0e --- /dev/null +++ b/events/2017/05-leadership-summit/session-notes/readme.md @@ -0,0 +1,6 @@ +**Per the [Template & Instruction Document](https://docs.google.com/document/d/1ncrfiVEy_WELqZaNdYOX0_9uuKzuTikgVC-mz2Izsc4/edit?usp=sharing), +upload your session notes here with the name format**: + +*HHMM-HHMM_SESSIONTITLE.md* + +where HHMM is the time in 24-hour format. diff --git a/events/2017/12-contributor-summit/ContribSummitInformation.md b/events/2017/12-contributor-summit/ContribSummitInformation.md new file mode 100644 index 00000000..7a6df6a3 --- /dev/null +++ b/events/2017/12-contributor-summit/ContribSummitInformation.md @@ -0,0 +1,70 @@ +# 2017 Kubernetes Contributor Summit Information +fka DevSummit + +## What: +The Contributor Summit provides an avenue for Kubernetes contributors to connect face to face and mindshare about future community development and community governance endeavors. + +In some sense, the summit is a real-life extension of the community meetings and SIG meetings. + +## When: +December 5th, 2017 (before KubeCon) +All day event with happy hour reception to close + +**Agenda:** +Times in CST +- 08:00 am - Registration and light breakfast +- 09:00 am - Welcome and start of content +- 12:00 pm - Lunch provided +- 01:00 pm - Sessions resume +- 05:00 pm - Happy Hour onsite + +View the complete session schedule [here](/community/2017-events/12-contributor-summit/schedule.png). +Session schedule will be available onsite in print as well as on TVs. + +## Where: +Austin Convention Center +500 E Cesar Chavez St, +Austin, TX 78701 +(same location as KubeCon) + +**Registration:** +You'll pick up your summit badge at the same registration tables as KubeCon.* +Level 1, near Hall 1 + +**Breakfast:** +Level 3, Outside of Meeting Room 5 + +**Sessions:** +Level 3, Meeting Room 5 - Welcome @ 9am +Level 3, Meeting Room 4, Meeting Room 6a, Meeting Room 6b - Breakout session rooms + +*_Note-Your summit registration is NOT your KubeCon registration. Tickets are almost sold out for KubeCon, please purchase those separately from the [event page](http://events.linuxfoundation.org/events/kubecon-and-cloudnativecon-north-america/attend/register)._ + +## Invitations: +Selected attendees are Kubernetes upstream contributors including SIG members and lottery winners from a [members of standing](/community-membership.md) pool. +We realize that this is not the best approach now that our community is growing in exponential ways. In 2018, we will be unfolding a new strategy for bringing our contributors together so all voices can be heard. + +Invites went out on October 19th. There are ten spots left. Please reach out to parispittman@google.com to claim one. + +## Format: +"loosely-structured unconference" +Rather than speakers and presentations, we will have moderators/facilitators and discussion topics, alongside all-day completely unstructured hacking. + +The discussion sessions will be in an open fishbowl format — rings of chairs, with inner rings driving the discussion — where anyone can contribute. The various sessions will be proposed and voted on by the community in the weeks leading up to the event. This allows the community to motivate the events of the day without dedicating precious day-of time to choosing the sessions and making a schedule. + +There will be 2 rooms dedicated to these sessions running in parallel all day. Each session should last between 45 minutes and an hour. There will be a smaller room available for unstructured discussion all day. + +## Call for Topics: +Call for topics and voting is now closed. You can view the complete list of proposed topics and abstracts [here](https://docs.google.com/spreadsheets/d/1miMinwk3Cp_4KV0xj36gIT3XdN4JtDcnAhkLZxG-qCQ/edit?usp=sharing). + +## Desired Outcomes: +* Generate notes from the sessions to feed the project's documentation and knowledge base, and also to keep non-attendees plugged in +* Make (and document) recommendations and decisions for the near-term and mid-term future of the project +* Come up with upcoming action items, as well as leaders for those action items, for the various topics that we discuss + + +## Misc: + +A photographer and videographer will be onsite collecting b-roll and other shots for KubeCon. If you would rather not be involved, please reach out to an organizer on the day of so we may accomodate you. + +Further details to be updated on this doc. Please check back for a complete guide. diff --git a/events/2017/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG b/events/2017/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG new file mode 100644 index 00000000..c866d23c Binary files /dev/null and b/events/2017/12-contributor-summit/Meeting Room 4ABC - 1st set, Tues fishbowl.PNG differ diff --git a/events/2017/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG b/events/2017/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG new file mode 100644 index 00000000..8c334121 Binary files /dev/null and b/events/2017/12-contributor-summit/Meeting Room 6A and 6B - 1st Set, Tues fishbowl.PNG differ diff --git a/events/2017/12-contributor-summit/breaking-up-the-monolith.md b/events/2017/12-contributor-summit/breaking-up-the-monolith.md new file mode 100644 index 00000000..265dcd60 --- /dev/null +++ b/events/2017/12-contributor-summit/breaking-up-the-monolith.md @@ -0,0 +1,76 @@ +# Breaking Up The Monolith + +Note Takers: Josh Berkus(@jberkus), Aaron Crickenberger (@spiffxp) + +Here's what we're covering: build process, issue tracking, logistics. + +## Question: are we commited emotionally 100% to splitting the monolith + +Opinion: commited, but need to define what that means (past provides the impetus) + +We've been trying [the monolith] for so long and it's too expensive. + +- erictune: as the project matures the core can't keep growing at the same rate +- mattfarina: reason to break it up - developer experience,difficulty to contribute pushes people away from contributing (hard to step into issue queue, etc) +- clayton: I'm scared by this because kubectl is never going to be simpler, it may be easier to just write a new one +- erictune: ecosystem yes, more contributors... narrowly defined core no +- bburns: we don't do a good job of measuring the cost of this, we love breaking things up because it's "cleaner" but we're not estimating the cost in terms of the human effort and complexity +- lavalamp: respectfully disagree, we _have_ estimated the cost, knew it was going to be painfu but we haven't had a choice +- timstclair: nobody has ever answered the question to be of how we're going to deliver a set of binaries as part of a release, there isn't a cohesive plan for doing this +- timstclair: how are you actually going to get test infra to test all the things +- bburns: how do you actually find the commit that causes a failure in e2e +- lavalamp: have you see the doc I have posted everywhere this comes up? (TODO: link) main repo becomes integration point, binary artifacts produced by other repos +- clayton: kubectl is a very "big" thing, if we said the problem is that kubectl itself is too big, it might be better to focus on something new and novel, it might be better to build a community around that +- dims/matt: can we have a list of four or five items we want to move out in priority + - Kubectl + - Client-Go? (but that's already published separately) (this is way too involved for this session) + - Try to tackle "how do we deal with client-go" elsewhere + - kubeadm is in main repo to catch release train, wants to move out, but it's fairly hard. We tried to move it out, but couldn't and follow the release train. +- clayton: government approach: why build one thing when we can build two for twice the cost? an (extracted) client-go that's all high-perf, a completely rewritten client-go that's human focused and more reusable + +## Question: Do we understand the problem we're trying to solve with the repo split + +Assumption: contributor velocity is correlated with velocity, new contributor experince +Assumption: "big tangled ball of pasta" is hard to contribute to + +- thockin: our codebase is not organized well (need to make it easier to actually *find* what you want to contribute to) one of the things we could do is "move code around" until it looks effectively like there are multiple repos in our repo? eg if we centralized all of the kubelet logic in one directory except for one util directory, maybe that would be an improvement +- jberkus: people who work on other large projects say that modularity is the way to go. Not necessarily seperate repos, but a modular architecture. +- thockin: what we've done with github bots alleviates a lot of the pain we've had with github +- dims: two problems + - vendoring in all kinds of sdk's that we don't care about, they get dragged in (e.g. AWS SDK) and if you're only working on eg: openstack related stuff, it's hard to get signoff on getting other stuff in if it's in your own repo it's easier to do that than in the main repo + - (guess we missed #2) +- erictune: we've already promised people cloud providers you can write in different ways, extensibility of apis, operators, if we deliver on all this we will have enough modularity to improve user/developer experience +- mattfarina: I think you're right about that +- First thing: we're breaking up cloud providers, it helps let the long tail of cloud providers go out + - what about storage providers, if we break them up there's a clear interface for storage providers +- second thing: here are api/components that are required, required but swappable, optional... how can you do that swapping around of stuff in the monorepo +- robertbailey: when I proposed this session I thought we had all agreed that breaking the repo was the way to go, but maybe we don't have that conensus could we try and figure out who is the decision maker / set of decision makers there and try to come to consensus +- dchen1107: I heard a lot of benefits of the split. So there's a huge cost for release management, as the release manager, I don't know what's in the other repositiory. Clear APIs and interfaces could be built without needing separate repositories. Gave example of Docker and CRI, which got API without moving repos. +- Example of Cloud Foundry, build process which took two weeks. How do we ensure that we're delivering security updates quickly? +- thockin: We can put many things in APIs and cloud providers are a good example of that. Splitting stuff out into multiple repos comes down to the question of: are we a piece of software or a distribution? You'll have to come to my talk to see the rest. +- spiffxp: Increasing our dependancy on integration tools will add overhead and process we don't have now. But I understand that most OSS people expect multiple repos and it's easier for them. Github notifications are awful, having multiple repos would make this better. The bots have improved the automation situation, but not really triaging notifications. How many issues do we have that are based on Github. Maybe we should improve the routing of GH notificaitons instead? +- solly: if we split, we really need to make it easier for tiny repos to plug into our automation and other tools. I shouldn't have to figure out who to ask about getting plugged in, we should have a doc. We need to make sure it's not possible for repos to fall through the cracks like Heapster, which I work on. +- bgrant: We're already in the land of 90 repos. We don't need to debate splitting, we're alread split. We have incubator, and kubernates-client. I think client has helped a lot, we have 7 languages and that'll grow. +- bgrant: the velocity of things in the monorepo are static +- thockin: if issues in the main repo are more than 6 weeks old, nobody looks at it. There's like 400-500 abandoned "network" issues. +- bgrant: we tested gitlab and gerrit, and importing kubernetes failed. We didn't find them that much better. +- spiffxp: we have hundreds of directories with no owners files, which is one of the reasons for excessive notifications. +- bgrant: kubernetes, as a API-driven system, you have to touch the api to do almost anything. we've added mechanisms like CRD to extend the API. We need SDKs to build kube-style APIs. +- dims: I want to focus on the cost we're paying right now. First we had the google KMS provider. Then we had to kick out the KMS provider, and there was a PR to add the gRPC interface, but it didn't go into 1.9. +- thockin: the cloud provider stuff is an obvious breeding ground for new functionality, how and if we should add a whole seperate grpc plugin interface is a seperate question +- jdumars: the vault provider thing was one of the ebtter things that happened, it pushed us at MS to thing about genercizing the solution, it pushed us to think about what's better for the community vs. what's better for the provider +- jdumars: flipside is we need to have a process where people can up with a well accepted / adopted solution, the vault provider thing was one way of doing that +- lavalamp: I tend to think that most extension points are special snowflakes and you can't have a generic process for adding a new extension point +- thockin: wandering back to kubernetes/kubrnetes "main point", looking at staging as "already broken out", are there other ones that we want to break out? +- dims: kubeadm could move out if needed, could move it to staging for sure +- thockin: so what about the rest? eg: kubelet, kube-proxy... do we think that people will concretely get benefits from that? or will that cause more pain +- thockin: we recognize this will slow down things +- lavalamp: there are utility functions that people commonly use and there's no good common place +- lavalamp: for kubectl at least it's sphaghetti code that pulls in lots of packages and makes it difficult to do technically +- thockin: do we think that life would be better at the end of that tunnel, would things be better if kubectl was a different repository, etc. +- timallclair: I'm worried about dependancy management, godeps is already a nightmare and with multiple repos it would be worse. +- luxas: in the kubeadm attack plan, we need to get a release for multiple repos. We need the kubeadm repo to be authoritative, and be able to include it in a build. +- pwittrock: how has "staging" improved development? can we see any of the perceived or hoped-for benefits by looking at staging repos as example use cases? +- lavalamp: getting to the "staging" state and then stopping is because api-machinery was unblocked once we got there +- thockin: the reason I consider "staging" solved, is you have to untangle a lot of the stuff already +- erictune: I would make a plea that we finish some of our started-but-not-finished breakaparts \ No newline at end of file diff --git a/events/2017/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md b/events/2017/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md new file mode 100644 index 00000000..66aadf88 --- /dev/null +++ b/events/2017/12-contributor-summit/cloud-native-design-refactoring-across-k8s.md @@ -0,0 +1,60 @@ +**Contributor Summit - KubeCon 2017** + +**Cloud Native Design/Refactoring across Kubernetes** + +*Lead: Joe Beda(**[@jbeda](https://twitter.com/jbeda)*)* + +*Co-lead: Amit Kumar Jaiswal(**[@AMIT_GKP](https://twitter.com/AMIT_GKP)*)* + +**Abstract** + +Explore how to cleanly support cloud-native behaviors, such as standardized Kubernetes logs, injectable configuration and common queryable APIs in Kubernetes components. While this discussion isn't only about containers, orchestrating OpenStack deployment/management within Kubernetes via OpenStack-Helm or Kolla-Kubernetes paves the way for better upgrade capabilities. They will also improve the ability to run individual Kubernetes services independently or in combination with other adjacent technologies. + +**Agenda** + +1. Cloud Native Ecosystems + +2. Kubernetes Abstractions & Primitives + +3. Kubernetes Design Patterns + +4. Refactoring across Kubernetes + +5. Benefits of using Kubernetes + +**Issues** + +** **- We’re looking for someone to help us out on issues related to refactoring across Kubernetes like [Issues#51405](https://github.com/kubernetes/kubernetes/issues/51405), [#46735](https://github.com/kubernetes/kubernetes/issues/46735), [#54090](https://github.com/kubernetes/kubernetes/issues/54090), [#55151](https://github.com/kubernetes/kubernetes/issues/55151) + + - Consolidating volume util files like *pkg/volume/util.go, pkg/volume/util/util.go, pkg/volume/util/volumehelper/volumehelper.go *[need better documentation of each file is to emcompass] + + - Enhancing e2e tests to track cloud provider’s API Quotas + + - Like changing fluentd to use CRI log Path and eventually deprecates the old container path + + - Issues with deploying/adopting Kubernetes for specific applications use-cases + +**Questions** + + - Security and granularity across Kubernetes + + - Kube API issues like it should not depend on *--cloud-provider* and *--cloud-config* + + - Helping us out with API documentation and Configuring Best Practices? + + - What are the new tools to deal with testing frameworks for NFV/SDN across Kubernetes? + + - Kubelet Flag subfields precedence v/s files/ConfigMaps to Kubelet Config + + - How to dynamically provision an AWS EBS volume from a snapshot? + + - Work around Object definition in OpenAPI schema like definition of the *PersistentVolumeSpec, PersistenceVolumeClaimSpec* + + - Work around support for FUSE client for K8s cephfs. + + + +**Audience Feedback** + + - + diff --git a/events/2017/12-contributor-summit/cloud-provider.md b/events/2017/12-contributor-summit/cloud-provider.md new file mode 100644 index 00000000..a18a0fb7 --- /dev/null +++ b/events/2017/12-contributor-summit/cloud-provider.md @@ -0,0 +1,86 @@ +# CloudProvider Update +*Lead: Walter Fender / cheftako* +*Notetaker: Jago Macleod / jagosan* +4pm + +Goals: + +Make it easy for any new cloud provider to be able to add support for new cloud provider without having to submit code to k/k repo. [good shape!] +For currently in-tree cloud providers to be able to build and release without having to ‘wait’ for upstream kubernetes. (e.g. security patches and features) +Also suboptimal that for technical reasons, other cloudprovider’s ‘init’s are being run in the hosting cloud provider’s environments. + +[TODO: name?]: From a user’s perspective, you might like a more modular cloudprovider. You might want ELB but not the storage from that cloudprovider. + +cheftako: where are we: + +There is a PR out that is a WIP that proves that in GCE it is possible to bring up a cluster + +Kube-controller-manager is disabled. cloud-controller-manager is working there + +Kube-mark tests are a challenge. No support for conditional behavior in test-infra. Now we need an n1-standard2 master. + +Other outstanding issues: + +Who has seen the following in the tests: + +If !GCE -> skip. + +Many raise hands. This is recognized as a gap that needs to be addressed. + +Also need volunteers for each of the cloud providers. Lot of work to be done. + +Thockin would like to minimize the amount of code that lives outside of k/k repo. If we were to take all of lifecycle and move it out of k/k, there is a lot of functionality that could diverge, or could be missing for a user in certain cloud providers. + +Take a page out of API Server book and make a generic controller manager and use for kube-controller-manager and cloud-controller-manager. + +Comment: spent a couple of days looking through the GCE work and found ~4 bugs. So there are a bunch of other + +Broke node controller out into 4 segments. + +Overview on where we are in the overall project: external cloud provicer + +We have a long way to go before all the in-tree cloud providers are moved out. + +One of the interesting questions is that eventually there are no in-tree cloud providers; there is now a distributed CI issue where all cloud providers have a mechanism through which to set up their own continuous testing and post results back to testgrid, to expose when changes to one area of the code inadvertently break one or many or all cloud providers. + +MS has a proof of concept basically done. Some questions: legally, what does this mean? E2E tests - how to make blocking. OpenStack -- in e2e tests, there is no tag to ensure nothing was broken in e2e. + +Jaice: to complicate matters, there may be primitives that make it necessary to make the testing much broader. There is a greater chance that the flakes occur in this world. + +thockin - on indemnity, we can make a dedicated repo that is still CNCF owned but controlled by cloud provider + +Exercise the top level interface + +Multiple levels of test here. In the final state, there is no ‘cloudprovider’ interface. You can test that binary / or binaries to test specific cloud implementations; then there is another level which is the e2e tests of basically everything that is the kubernetes functionality. + +When it comes to timing: the original plan was to depend on Flex Volumes. Subsequent discussions have tended toward depending instead on CSI as the volume solution. This means the timing is no earlier than Q3. + +Victory looks like this: + +Major cloud providers shipping and running cloud-controller-manager. Volumes can remain behind until CSI is production ready. + +Also, when we can eventually delete all the in-tree cloud provider code, thockin will buy the cake and the keg. + +Today, when you deal with CCM, and it says ‘what is my cloud provider’ it turns off cloud plugin, and volumes doesn’t work. There is, therefore, a new flag. Set cloudprovider=external and some other flag, can’t remember off top of head. Intention is that this will be a temporary second flag and will be removed as soon as possible. + +A lot of really good work has been done. Need to do a better job of organizing code in KCM & CCM. + +Open Question: will we ship cloud provider specific CCM’s as part of the kubernetes release? + +Or, what cloud providers are included or easily available with the binaries distributed in the Kubernetes release? + +Can we define better criteria than ‘you showed up before date xxxxxx’. + +Perhaps there is something that will work for a ‘vanilla’ system or locally, and some way to discover and install CCMs for available cloud providers. Likely the vendor / distributor will be packaging up some other process by which kubernetes is installed and configured. + +Thockin - think about what you do when you compile the linux kernel. Choose options during initialization and customize to hearts content. At the end, you get an artifact. Kbuild. Did a hack 18 months ago and proved it’s possible. + +thockin - do we have concrete list? Not a great list. We are going through the KEP process. AI: call to action. + +We are committed; we are making progress; we meet wednesdays at 10am Pacific Time. + +Fejta: think about a local provider. Move as much as possible onto something that is like minikube, e.g. Great enthusiasm for this concept. + +AI: fejta to share information on how to submit test results to testgrid and how to leverage the tooling for external cloud providers. + +Summary - yes! diff --git a/events/2017/12-contributor-summit/container-identity.md b/events/2017/12-contributor-summit/container-identity.md new file mode 100644 index 00000000..06a53a79 --- /dev/null +++ b/events/2017/12-contributor-summit/container-identity.md @@ -0,0 +1,168 @@ +Container identity + +Lead: Greg Castle + +How are people using k8s service accounts + +* Default service accounts? + +* User: + + * (Zalando) + + * 55 clusters + + * Only allow pre-set service accounts postgres "operator service accounts" + + * Don’t enable RBAC + + * Namespaces: usually use the default namespace, more sophisticated clients can use namespaces + + * Cluster per product + + * CRD that defines request for an OAuth2 token + + * Q: Would you want to tie it to a Kubernetes service account. E.g. annotation on a service account to get an OAuth2 token + + * (IBM) + + * Strict way of "cutting up cluster" + + * No team has access to the Kubernetes API + + * Humans do, pods don’t + + * Admins create service accounts and role bindings + + * Issues with pod authors in the namespace can run any service account. + + * Is there a missing binding to control the right to use a service account? + + * Namespace boundary + + * Application + + * (VMware) + + * 1 cluster + + * Projects are per-namespace (200 namespaces) + + * Wrote an admission controller between which pod is using which service account. Denies certain kind of changes. + + * Ownership model "I created this object, only I can change it" + + * Namespace but wanted sub-namespace primitives + + * Service accounts have labels, need to match the pod. + + * Q: Why not just different namespaces? + + * Don’t want to give users the ability to create namespaces + + * (Jetstat) + + * Dev, staging, and prod cluster + + * Namespace per team + + * Their developers don’t have permissions to create workloads + + * CI system is the thing that creates workloads, that controls stuff + + * (CoreOS) + + * Customers create namespaces that are controlled by CI/CD + + * Users have read-access to cluster + + * Central catalog controls the service account + + * Authoritative on RBAC + + * Catalog is currently controlled by CoreOS, can be used by users later + + * Namespaces + + * Catalog is enabled on a namespace + + * Also use service accounts to authenticate CI/CD systems + +* Container identity + + * Authenticate workloads against each other + + * Does this fit into the current way you use service accounts? + +* What about envoy istio? + + * Complementary efforts + + * Services can do service to service auth + + * Maybe not solving "I want to talk to s3, I want to talk to GitHub" + + * Give them a better way to provision x509 certs + + * Istio will be dependent on container identity + + * Istio and SPIFFE? + + * Istio is using SPIFFE conformant x509, not the workloads API + +* Q: how does Zalando RBAC CRDs? + + * Trust two engineers that have the permissions to create the CRDs + + * Emergency procedure with time limited API + +* Q: multiple clusters working together? + + * IBM: going to face it + + * CoreOS: thinking about users authenticating across multiple clusters through sharing public keys. + +* Liggitt: namespaces are the boundaries of trust + + * Originally thought about using pod templates so admins could create specific templates that pods MUST use. + + * Reference pod template in RC or deployment instead of inlining them + + * Never bubbled up to be the most important thing yet + +* Liggitt: Kubernetes API isn’t really designed for things that hold credentials + + * Moving the mounting and creation of the service account to the kubelet through flex volumes + + * Helps you leverage the node level integrations + +* Q: what about the secrets proposal? + + * KMS is being added + + * No change for encrypting the secret as you read it + +* Slides + + * Authorization should apply to the identity, rather than the namespace + + * Is multiple SA per namespace an anti-pattern? + + * Useful for bounding process within pods to certain permissions + + * Problem when a SA from cluster scoped manifests + +* Q: kerberos and vault bindings implemented as flex volumes + + * Is it important to have standard identity mechanisms? (Yes) + + * Can we add it to conformance? + + * Avoid lock-in for IAM + + * Cluster identity also becomes an issue too + + * Pod/UID/Namespace/Cluster + +* Potentially use OpenID Connect format so others can use that spec + diff --git a/events/2017/12-contributor-summit/current-state-of-client-libraries.md b/events/2017/12-contributor-summit/current-state-of-client-libraries.md new file mode 100644 index 00000000..c7ac0bad --- /dev/null +++ b/events/2017/12-contributor-summit/current-state-of-client-libraries.md @@ -0,0 +1,38 @@ +Story so far is described at https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/csi-client-structure-proposal.md +- linked from https://github.com/kubernetes-client/community/blob/master/design-docs/clients-library-structure.md + +Would like libs to be more "fluent" - should join up with the native language features e.g. JavaDoc, per-platform + +OpenAPI (Swagger) has limitations which force ugly workarounds. + - e.g. doesn't cover returning different types in response to a call e.g. a result or an error. + - OpenAPI 3 fixes a number of these limitations + +Key difficulty is which verbs apply to which objects - Go doesn't natively have this concept. + +OpenAPI doc is produced by running an api-server, which knows how to dispatch verbs to objects, and having it generate the OpenAPI + +Should we deprecate SPDY in favour of websockets? (probably yes) + +What do people want in a client library? + - Go lib smaller than 40MB + - Go lib with dynamic types (this exists?) + - Rust + - C++ + +Are there client libs for things like service catalog? Where do those live? + +How can clients talk protobufs to api-server? Set the content-type. + +K8s protobuf def uses an 'envelope' type covering things like storage version + +Protobuf not self-describing so not great for api-server CRUD operations + +A few bits of extra information in the protobuf definition would be great - e.g. pluralisation + +Client SIG is relatively under-represented and relatively easy to join in - please come along! + +kubeconfig semantics are not standardised - when reimplemented in different languages this can give unexpected results. Example: URL with no scheme supported by Go but not Java + +How should clients deal with rolling authorisation certificates? + +There are type wrinkles, like "intorstring" and "quantity" \ No newline at end of file diff --git a/events/2017/12-contributor-summit/dashboard-ux-breakout.md b/events/2017/12-contributor-summit/dashboard-ux-breakout.md new file mode 100644 index 00000000..3dad6fe2 --- /dev/null +++ b/events/2017/12-contributor-summit/dashboard-ux-breakout.md @@ -0,0 +1,94 @@ +Kubernetes Dashboard UX breakout session 12.5.17, led by Rahul Dhide ([rahuldhide](https://github.com/rahuldhide)) and Dan Romlein + +* **Resources:** + + * Dashboard [User Types #975](https://github.com/kubernetes/dashboard/issues/975) + + * Dashboard [User Types and Use Cases](https://docs.google.com/document/d/1urAlgRP7AbcdsOMQ_piQQ6O1XTDIum_LmOUe8xsC4pE/edit) + + * [SIG UI weekly](/sig-ui) + +* **Notes** + + * 2018 Dashboard strategy. + + * [Deck](https://docs.google.com/presentation/d/1q1G1vWCrenI3GVsyF4d-2rpyVrdJgFW7fIbvcAAd9Lg/edit?ts=5a26f250) + + * [Github issue](https://github.com/kubernetes/dashboard/issues/2556) + + * **Kubectl access via Dashboard**. + + * Dhaval: Provide context to issues. + + * **Third-party Widgets**. + + * **Custom Views**. + + * Dhaval: Custom views will be very useful to share the event details, contextual information, and logs with specific time ranges. It will help our development teams to quickly analyze the issues. + + * Henning: UI should allow users to pick the important properties in different views/widgets. + + * **Integrations and CRDs**. + + * **Onboarding experience**. + + * Jared: Currently there is no crosslinking between docs and the UI. We can explore the concept and impact further. + + * **Design system.** + + * e.g. Standard for how a pod’s status is displayed. + + * Different use cases/personas + + * application developer + + * application operator + + * (multi-)cluster operator + + * **Feedback from Dhaval and Hennings:** + + * "We don’t use Dashboard, because of lack of authorization control." + + * "Dashboard today caters to the dev perspective, which is OK." + + * But for ops, currently missing dependency stacks (e.g. OS version) "I want to know different node versions." + + * "Our developers use Dashboard for the logs" + + * "When we perform troubleshooting & debugging we expect 30 min before and after incident. + + * Want to be able to link users to docs for more info; "What’s a pod? What’s a deployment?" + + * *Contextual docs* displayed in UI. + + * Idea: Dashboard could scrape docs. + + * Kubernetes docs working on expanding [glossary](https://kubernetes.io/docs/reference/glossary/?fundamental=true) + + * Dashboard is backwards compatible. + + * Demo of [Kubernetes Operational View](https://github.com/hjacobs/kube-ops-view) + + * Use Case: + + * Onboarding: explain resource limits vs. resource requests. + + * Quickly looking at a cluster and knowing what’s going on. + + * "I really like this UI" + + * Wanted to gamify K8s with this UI. + + * "My cluster has 118 nodes, so the ability to filter would be important." (general scale issues) + + * "Problem we’re running into is that the number of nodes will crash the browser, so we need some way to select cluster first" + + * Defining a view is hard, Dashboard shouldn’t attempt to do that. + + * Use case for custom Dashboard re-skinning. + + * "My exec looks at the look and feel." + +* Kubernetes Dashboard 2017 User Survey: [https://docs.google.com/forms/d/e/1FAIpQLScnxeub_xh7Lp4iZO1RKdTgIYK_cTwqFKv1WD-Cue4tZHcbhw/viewform?usp=sf_link](https://docs.google.com/forms/d/e/1FAIpQLScnxeub_xh7Lp4iZO1RKdTgIYK_cTwqFKv1WD-Cue4tZHcbhw/viewform?usp=sf_link) + diff --git a/events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md b/events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md new file mode 100644 index 00000000..50be4b66 --- /dev/null +++ b/events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md @@ -0,0 +1,134 @@ +# Kubernetes Ecosystem + +Notes by @directxman12 + +* How do we e.g. have an object validator + + * Went looking, found 2, second b/c first didn’t work well enough + +* How do we enable people to build tools that consume and assist with working with Kubernetes + + * Kube-fuse, validatators, etc + + * How do we make those discoverable + + * Difficult to find via GitHub search + + * Difficult to find via search engines (find blog posts, etc, and not the tools) + +* Proposal: structured content (tags, categories, search) for registering and discoverability + +* Are there examples of ecosystems that we can follow + + * Package managers (PyPI, crates.io, NPM) + + * Doesn’t quite fit one-to-one b/c some stuff is best practices, etc + + * Docs, stuff like CNI plugins, etc doesn’t actually work well the same view as things that run on Kubernetes + + * At the basic point, just need to find what’s there + + * Traditional package managers focus on consuming the packages + + * If you don’t have packaging, it’s hard to approach (see also: Freshmeat problems) + + * Hadoop: classes that map the Hadoop ecosystem, infographs + + * Wordpress, Drupal are good examples + + * Ansible Galaxy + + * Chrome Extensions/Eclipse plugins + + * Look for things tagged, if comments say "broken" and last update is old, don’t use it + + * Packagist (PHP package repository) + + * Integrates with GitHub, pulls in details about updates, README, extensibility, etc from GitHub + + * Just helps with discoverability + + * Steam + + * Has curated lists by users + +* Opinion: End users need focused, distributable bundles + + * Most people don’t need to do all of everything + + * Different systems for apps vs critical infrastructure + + * Critical infrastructure doesn’t change much + + * Still need to discover when initially building out your system + +* Issue: people get overwhelmed with choice + + * We don’t want to endorse things -- users should choose + + * We could let people rank/vote/etc + + * For example, what’s wrong with an "awesome list" + + * Need to look at human-consumable media, not necessarily machine-consumable + +* Question: do we currate + + * Do we require "discoverable" things to be maintained/use a CLA/etc? + + * Opinion: no, we can’t possibly curate everything ourselves + +* It’s problematic if you can discover new things, but they’re not supported by your Kubernetes distros + + * Not as much a problem for apps stuff, but harder for infrastructure + +* Doesn’t GitHub have labels, stars, etc + + * Yes! + + * We could just say "always label your GitHub repo with a XYZ label if you’re a CRI plugin" + + * Comes a bit back to curration to discover benefits of each + + * Enterprises, gitlab make this infeasible + +* Core infrastructure is a bit of an edge case, perhaps focus on addons like logging, monitoring, etc + + * Still comes back to: "if distro doesn’t support well, will it still work" + +* Issue: there’s things people don’t know they can choose + + * E.g. external DNS providers + +* Have a partially curated list of topics, but not curate actual content + + * Maybe leave that up to distros (have different collections of options -- e.g. open-source only, etc) + + * Have "awesome-kubernetes" + +* Let SIGs curate their lists? + + * Having all the SIG be different is difficult and confusing + + * SIG leads don’t necessarily want to be the gatekeepers + + * We don’t necessarily want to tempt SIG leads with being the gatekeepers + +* If we have something "official", people will assume that stuff is tested, even if it’s not + +* Can we just have distributions that have way more options (a la Linux distros) + + * There are currently 34 conformant distros + +* If we have ecosystem.k8s.io it’s really easy for people to find how to find things, otherwise could be hard + + * E.g. people don’t necessarily know awesome lists are a thing to search for + +* Someone should do a prototype, and then we can have the conversation + +* Question: where should this convo continue + + * SIG Apps? + + * Breakout group from SIG Apps? + diff --git a/events/2017/12-contributor-summit/extending-kubernetes.md b/events/2017/12-contributor-summit/extending-kubernetes.md new file mode 100644 index 00000000..ee21aea2 --- /dev/null +++ b/events/2017/12-contributor-summit/extending-kubernetes.md @@ -0,0 +1,215 @@ +# Extending Kubernetes +Note Taker: Clayton Coleman ([smarterclayton](https://github.com/smarterclayton)) + +* Questions + + * Do we have enough extension mechanisms? + + * See below + + * Implementing network injection that isn’t a CNI injection of some form is hard + + * e.g. adding in arbitrary network devices, for example + + * Are Flex Volumes enough? + + * Maybe? + + * Are we doing ok on kubectl extensions? + + * Yes, we’re heading in the right direction with plugins + + * Kubectl itself should be developed using its own mechanisms + + * Extension points: + + * OpenAPI metadata (operate on object w/o knowing about it) + + * Subresources (generic API-level interfaces for certain facets) + + * Plugins (git-style) + + * Can we do custom validation in kubectl? + + * Do it via admission webhooks (beta in 1.9) + + * Can run validation asynchronously, and report it (put a condition in) + + * Client-side validation is iffy + + * Should we have phased hooks? + + * Should more complex application lifecycle layer on top? + + * Are we consistent enough across our hooks to enable users to build something sane? + + * Can we do referential integrity + + * Technically, with a webhook + + * Generally not the best idea (causes issues with components that don’t expect it) + + * Can maybe do with initializers on a namespace + + * Generally go for eventual consistency (e.g. wait for the secret to exist before starting the pod) + + * Reasons + + * Surface errors to users synchronously + + * Do it on the client-side + + * Avoid dealing with the full matrix of failure modes + + * How do we not re-invent a service mesh with auth webhooks? + + * It’s an open question + + * Can we do conversions on CRDs + + * Maybe with a webhook (ongoing discussion) + + * Why aren’t Custom API servers easy enough + + * Need OpenShift certificate signing mechanisms in Kube, or similar (also exists similarly in Istio) + + * Storage + + * Re-use existing etcd + + * Use your own etcd + + * Planned backing custom API servers with CRD storage + + * Why aren’t they more uniform + + * Because they came at different times + + * It’s hard to fix them now (need more versioning) + + * Different layers have different needs + + * Declarative is API + + * Below Kubelet is gRPC + + * gRPC for KMS, CSI + + * CNI is shell execution (mainly for legacy reasons) + + * Can we make custom controllers easiers? + + * OperatorKit + + * Need better docs (being worked on) + + * Untyped vs generated typed informers and listers + + * No Go generics exists + + * Can use interfaces + + * Can use conversions (may be harder than it needs to be) + + * Can wrap in a generic type (e.g. RBAC types) + + * Generating clients for CRDs (look for stts’s blog post on generators and informers) + +* Existing extension mechanisms + + * API Extensions + + * External APIs (Aggregated APIs) + + * Custom Resources + + * Admission/Early-Phase ext points + + * Initializers + + * Can’t do in updates + + * Webhooks + + * Need to make them easier to implement (and a good example) + + * Pod Presets (ish) + + * Webhooks have to be fast, initializers are more async (normal controller style, with restraints) + + * Finalizers (late-phase ext points) + + * Flex Volumes + + * Being used to prototype container identity work, too + + * CSI (soon™) + + * (grpc) CRI + + * (binaries) CNI + + * (webhook) Auth plugins + + * Authz + + * Authn + + * Groups from authn hook ??? + + * (API server) Custom metrics API servers + + * (grpc) Device plugins + + * (grpc) KMS (Key Management) + + * (git style) kubectl plugins + + * (API usage) Any controller + + * External Cloud Provider + + * Pod lifecycle isn’t extensible + + * Object phase + + * Init containers (do exist) + + * defer containers + + * Lee’s debug container + + * Logging plugins + + * Was a proposal for logging volumes, didn’t get follow-up + +* New Extension type things + + * Enumerations in the API + + * Conditions (new condition types) + + * Loose coordination between multiple controllers + + * Signal to end users + + * Exists until formalized as a field + + * runc hooks + + * Could be a CRI concern + + * Optional CRI sub-interfaces? + + * Identity injection (custom CA certs in every pod, etc) + + * Simplifying the creation of controllers with controller generation ie. metacontroller: [https://github.com/GoogleCloudPlatform/kube-metacontroller](https://github.com/GoogleCloudPlatform/kube-metacontroller) + + * API server builder: [https://github.com/kubernetes-incubator/apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder) + + * Operator pattern toolkits: + + * Rook Team: [https://github.com/rook/operator-kit](https://github.com/rook/operator-kit) + + * GiantSwarm: [https://github.com/giantswarm/operatorkit](https://github.com/giantswarm/operatorkit) + diff --git a/events/2017/12-contributor-summit/feature-roadmap-2018.jpg b/events/2017/12-contributor-summit/feature-roadmap-2018.jpg new file mode 100644 index 00000000..6b69204a Binary files /dev/null and b/events/2017/12-contributor-summit/feature-roadmap-2018.jpg differ diff --git a/events/2017/12-contributor-summit/feature-roadmap-2018.md b/events/2017/12-contributor-summit/feature-roadmap-2018.md new file mode 100644 index 00000000..d2ae01ac --- /dev/null +++ b/events/2017/12-contributor-summit/feature-roadmap-2018.md @@ -0,0 +1,336 @@ +Contributor summit - Kubecon 2017 + +**@AUTHORS - CONNOR DOYLE** + +**@SLIDE AUTHORS ARE THE PRESENTERS** + +**@SKETCHNOTES AUTHOR DAN ROMLEIN** + +# 2018 features and roadmap update + +Presenters: Jaice, Aparna, Ihor, Craig, Caleb + +Slidedeck: https://docs.google.com/presentation/d/10AcxtnYFT9Btg_oTV4yWGNRZy41BKK9OjK3rjwtje0g/edit?usp=sharing + +What is SIG PM: the "periscope" of Kubernetes + +* They look out for what’s next, translate what’s going on in the community to what that means for Kubernetes + +* Responsible for Roadmap and Features Process + +Understanding the release notes is difficult sometimes since the docs aren't always done by the time the release team is compiling the notes. + +## Retrospective on 2017 + +* What did we do since Seattle + +* Feedback on how we can enhance SIG-PM + +* Moving from "product-driven" to "project-driven" where SIGs are defining their roadmaps based on market, end-use input etc. + +Major 2017 Features: + +* (Apps) Workloads API to Stable + +* (Scalability) 5k nodes in a single cluster + +* (Networking) NetworkPolicy + +* (Node) CRI, GPU support + +* (Auth) RBAC stable + +* (Cloud providers) Out of core + +* (Cluster Lifecycle) kubeadm enhancements - road to GA in 2018? + +* (Autoscaler & instrumentation): custom metrics for HPA + +* (Storage) CSI (Container Storage Interface) + +How did we do on the contributor roadmap? + +* [See 2017 roadmap slides](https://docs.google.com/presentation/d/1GkDV6suQ3IhDUIMLtOown5DidD5uZuec4w6H8ve7XVo/edit) + +Audience Feedback: + +* Liked that it felt like there was a common vision or theme last year. + +* Liked that there was a PM rep saying "do docs", "your tests are failing" etc + +* Leadership summit 6 months ago: shot heard called was "stability releases, stability releases". Not sure that 1.8 was really a stability release, not sure 1.9 is either. Will 2018 be the year of stability (on the desktop) + + * (Brian Grant) Come to the feature branch session! + + * Notion of stability needs to be captured as a feature or roadmap item to talk and brag about. Quantify, talk about as roadmap item + + * Idea for 2018: how do you measure and gamify stability? See a number in the red, people will want to fix. Testing, code quality, other metrics - might improve stability organically + + * Context of stability and testing: achievement was conformance program. 30+ conformant distros! + + * Want to see project continue to be useful: within your SIG, invest in conformance, extending suite. Going back to what is and is not k8s - define core, extensions: don't compromise the stability of the core. + + * Please come see Eric Tune and define stability : + + * "cluster crashed" + + * "too many features" + + * "an API I was using stopped working" + + * "community is chaotic, how do I navigate that" + +* There are many new alpha features in each new release. Please prioritize graduating and stabilizing the existing features. (More than 50 APIs already) + +* Looking for volunteers on writing a stability proposal? + +* Jaice has one already! + + * *May* have broken the comment limit on Google Docs + + * Need to define lens: + + * architecture, community etc; look at a proposal under each. + + * Brian is working on arch stability. + + * Contribex is looking at mentorship and ladder. + + * Myriad of ways to approach problem set. How do we mature the processes of the Kubernetes ecosystem? + +* Looking for co-authors? + +## Proposals and KEPs + +(Caleb) + +Please hang out in SIG-Arch, SIG-Contribex, SIG-PM to drive this process forward + +Looking at "is this feature ready to move to the next stability milestone?" (Alpha to Beta, Beta to GA etc) + +* Proposals are now **K**ubernetes **E**nhancement **P**roposals + + * Piece-by-piece over on more multiple releases (living documents) + + * Looked at a lot of other open source projects, e.g. the Rust community (RFC Process) + + * designed in the era of GitHub; decided on a lightweight process that works well with the VCS. + +* Talk about what we want to do without a long spec doc, about what we agreed to ahead of time, but* don't want to diverge 2 years later*. + +* Helps tracking individual features (easier to read release notes) + + * Release note writing take tracking down a lot of docs, GitHUb issues, design docs, Slack and Google Group comments; combine from a bunch of places + + * Hard to tell from the release notes what's important and what's a minor detail. + +* Every SIG should set their own roadmap - the KEP proposal enables that. + +* Template that asks you to think ahead for the lifecycle of the feature; let people know what you're planning to do. + + * It's a medium for comms; not saying "It has to be done this way" but saying why this is important. + + * Inspired by "[Toward Go 2](https://blog.golang.org/toward-go2)" blog post by rsc + +* Has been tested - [draft KEP for Cloud Providers](https://github.com/kubernetes/community/pull/1455), Tim St. Clair has tested. + +* Want to make easier for new contributors to write KEPs. + +* Starting with "what is a unit of work, how do people care" + +Questions: + +* Are KEPS google docs, or pull requests, etc? How do you submit one? + + * Original intend: something that lives in source control. Discoverable like any part of the code. Attempt to combine design proposals and umbrella GitHub issues, link to 10s of other issues. They will live as long as we're a project; doesn't depend on hosting providers. + + * Vision is that writing KEPs, know from them what the roadmap is; can write the blog post based on the value articulated in the KEPs. + + * Right now they are [buried in community repo](/contributors/design-proposals/architecture/0000-kep-template.md) 3 levels deep: a lot of great feedback so far. Joe wouldn't object to making it more discoverable. + + * Kep.k8s.io for rendered versions? + + * Rust community has a sub-repo just for this (rust-lang/rfcs) + + * More than one person has said that KEPs weren't known about - move to somewhere discoverable sooner rather than later. Who can own that action? Matt Farina from Samsung is keen to help but doesn't have resources to lead. + + * *Can only have its own repo if we get rid of features repo!* + + * Don't want anyone to do anything not adding value to work; hope is that KEP is worthwhile and adds value. Caleb will help drive, and create repos as needed. + +## Features + +(Jaice) + +Features repo and process: I will say what I'm not happy about and what I've heard, but I do want to say there has been so much work from Ihor and SIG-PM to get where we are. If you haven't seen the machinations of feature/release product you won't know! + + +At velocity we have outgrown the notion of a central body leading. Seeing increasing cross-SIG concern where some SIGs rely on others to get their work done. + +We need to find ways to detangle those dependencies earlier. + +KEPs are focusing on enhancements, changes in ecosystem. A feature has a connotation of being user facing or interactive. KEP can be for something contributor facing, doc facing transparent. Get out of mindset we're delivering a "thing" - we're delivering value to user, contributor community, or both. + +Currently the process is cumbersome. We want to follow agile principles about local control, local understanding, sharing amongst teams. + +### The steel thread + +KEP provides opportunity for "steel thread" of custody. A KEP, as a living Markdown doc with metadata, lets you see high level idea at any group of time. A SIG can break this down into meltable ideas for each release. A KEP can last multiple milestones. In terms of features/issues, defined by SIGs, issue should be actionable. If a SIG writes an issue for that release milestone it should be approachable by any contributor who is a SIG member. + +PRs roll up to the issue: links to this issue, which links to this KEP. For the first time we would be able to see at the PR level, what the grand scheme behind everything we do, is. Not heavyweight - just linking of issues. Limit administrivia, paperwork to delivery value. + +Q: + +* For CloudProvider - discovery, had an idea, people started digging in; how do you keep updating the KEP? Do you update as you go, you odn' tknow what you need? + + * Yes, it's a living doc first and foremost. Has metadata (alpha, beta, GA). The issues worked on per milestone - say you pick 3, you document those issues; if during the course of the PRs to complete those issues you realise it's a misstep, you close the issue, you update the KEP, say you're modifying this; look at prior versions to see what it looked like before/what it looks like now. As you move to next release milestone the issues reflect that change: in terms of KEP, issues, planning. + +* Give an analysis on why issues in feature repo didn't solve this problem and why KEPs will? + + * From features standpoint: SIGs interacted with features only when they had to. By trying to keep all that info separate from PRs, issues in each milestone: no way to tie that work back to the feature issue. No way to easily understand where in this features repo issue, long if multi-milestone: where was work, and the link to the issue? Eliminate the work + + * KEP is not solving that problem. KEP is saying "how do we best define and discuss the value we're adding to the ecosystem". Learns from patterns and antipatterns of other communities. + + * Features process is central body of people not doing the work. + + * Some friction with the GitHub mechanics of issues, relabeling quarterly, etc; would be nice to keep pace with the number of issues. Moving to files to provide value will help make that clearer. + + * Managing issues in the features repo: hundreds of issues from the last year, created spreadsheets etc. Bringing value but consuming extra resources. Not synced with features repo. Good we have a spreadsheet, but difficult to manage. + + * Started going through this process in SIG-Cluster LIfecycle: replacing GitHub thread (no one updates top) with a living document (use git history for mutations; see concise summary) - think it will be a huge improvement. + + * KEPs are in Google Docs now, haven't converted to PRs + +* Does this mean the features repo is going away? + + * "Yes, eventually". + +* We need clear communication about where we are in this process. Are KEPs required, encouraged, etc? Trying with one project, be useful to know what the granularity is. + + * "It's in Alpha now" - trying to validate some assumptions. + + * Has momentum with SIG-Arch and SIG-PM + + * Assumption we will try and see if it works. + + * Want to steward people into trying it to see if it's valuable. If not, how do we make it so? + + * Community size and velocity now makes it difficult to radiate information to get what you need to know. + + * Kubernetes 1.10 would be a great place. + +* Will it still be true in 1.10 that you need features? Can you have KEP instead of a Feature issue? Make it very obvious for 1.10 please. + + * One thing we need to sort out + + * 1.10 will have existing features process + + * Cluster Lifecycle are experimenting with how to do differently + + * Would love to see SIGs try the KEP process but it's not a full surrogate for the features process yet. + +* Existing features can be sorted, filtered etc - will there be tooling around KEPs? Until that's ready, I wouldn't want to switch + + * Proposals are different to features: issues will be associated with a KEP. In some ways it will be better as it's in the repo itself. + +* How are the issues tied to the KEP? + + * Ties to this markdown file, in /kep/____ + + * We need to work out the details. + + * When I create issue template, it will have a link to that KEP. + + * *Make sure it's searchable!* + +* (Jago Macleod) Be explicit of scope of a KEP. A trend to more SIG ownership, code, roadmap etc; context is a SIG plans their own work. Certain faster moving SIGs, more capacity, to solve problems in the wrong component. Some KEPs will span SIG boundaries and should be explicit about this in comms. + +* (Tim Hockin) GitHub UX is not going to be great for this. It's not built for what we're trying to do. All of this predicates on having an actual site that manages, a web app? + +If that's true, can we start to collect the expertise? + +Is there a SaaS tool for this? + + * See other projects using tracking tooling, used on files in source control + + * Won't be pretty or searchable in first iteration. + + * Want to see built out as they're consumed. Don't build tooling before people are using the process + + * *GH search is less than usable* + + * Do you have a place to host this? We will find a place to host if someone is willing to write. Matt will help write. + + * As someone involved with Maven repositories (trello) - it's a total pain in the neck. More in favour of PRs, discoverability, etc. Keep PRs for process. Push a site for discoverability. + +* (Joe Beda) Current processes are discussion, argument, write-only: comment threads no-one reads. Make it more discoverable, more readable: check stuff into GitHub, use a static site generator, publishes it somehow, crosslinks between documents. Just like when you go to an RFC, reference one there's a link; that's the ecosystem of discoverability we want. + + * If someone comes to project and we have no way of telling what's happening. + +* (Eric Tune) I created features process so I'm a little attached. This discussion is a refactor vs rewrite debate. The feature repo template is there; in GitHub; change it. See how many incremental changes we can make to solve proposals. Put fields there and yell at people who don't fill it in. + +* (Angus, Bitnami) As someone involved in Rust community: + + * fairly well-read Rust weekly news summary, including a section with a summary on outstanding proposals, broken down into early and late discussion phases. Read late phase to see what's a done deal vs. what's up in the air. There's also a RFC podcast, where they get a couple of people, have a chat show about what's involved in that proposal. Lots of ways as a community member to stay up to date. + + * Fixed timeline: trying to get approval. If nothing happens by the end it's approved by default. + + * May not want to copy but good to know. + +* (Daniel Smith, Google) summarising: problems are mostly discoverability: we'll write tooling. Why can't we write tooling against that existing process? Both current and hypothetical new process suffer + + * Interacting with objects in GitHub is hard at our scale, we have a limited number of tokens. + + * Procedural aspects: if I look at a PR, there's a link to an issue: that will tie up to a KEP. + + * Discoverability of relationships: exposed in the API. Links on GitHub are implemented by full-text search, not hard to do this. + +* (Chen Goldberg) Schedule follow-up sometime this week - communicating is hard, we're all here! + +* (Henning, Zalando) Structured format with some metadata: all in one repo, or distributed amongst incubator projects etc? Are KEPs with a unique identity going to live in other project repos? Was this an idea? + + * Idea is to have as consolidated as possible: given committee questions of "what is Kubernetes, what follows our PM norms". Problem is visibility for people who trust workloads in the software we create. Want to provide this so someone can determine why a thing was done a certain way. Projects outside the core repo: would follow a similar process in a perfect world. + +If you're not excited about features process, try a KEP! + +Reach out to SIG-PM - calebamiles@ + +### The long view + +(Jaice) Have planning sessions about what SIGs are hoping to deliver for any milestone. Want to facility planning meetings in a more structured way (Planning as a Service). I did this for a proposal SIG-Cluster Lifecycle are working on: to have the discussion early and untangle dependencies, see when things could go off the rails, etc. Will talk to SIG leaders. + +This planning activity will be one of the key success factors for the project moving forward. + +Roadmap for 2018 (30min summary) +-------------------------- + +Notes by @jberkus + +Speakers (check spelling): Apprena Singha, Igor, Jaice DuMars, Caleb Miles, someone I didn't get. SIG-PM + +We have the roadmap, and we have this thing called the features process, which some of you may (not) love. And then we write a blog post, because the release notes are long and most of the world doesn't understand them. + +Went over SIG-PM mission. We had several changes in how the community behave over 2017. We are moving to a model where SIGs decide what they're going to do instead of overall product decisions. + +2017 Major Features listed (workloads API, scalability, networkpolicy, CRI, GPU support, etc.). See slides. The question is, how did we do following the 2017 roadmap? + +Last year, we got together and each SIG put together a roadmap. In your SIG, you can put together an evaluation of how close we came to what was planned. + +Q: Last year we kept hearing about stability releases. But I'm not sure that either 1.8 or 1.9 was a "stability release". Will 2018 be the "year of the stability release?" + +Q: Somehow the idea of stability needs to be captured as a feature or roadmap item. + +Q: More clearly defining what is in/out of Kubernetes will help stability. + +Q: What do we mean by stability? Crashing, API churn, too many new features to track, community chaos? + +Q: Maybe the idea for 2018 is to just measure stability. Maybe we should gamify it a bit. + +Q: The idea is to make existing interfaces and features easy to use for our users and stable. In SIG-Apps we decided to limit new features to focus everything on the workloads API. + +Proposals are now KEPs (Kubernetes Enhancement Proposals) are a way to catalog major initiatives. KEPs are big picture items that get implemented in stages. This idea is based partly on how the Rust project organizes changes. Every SIG needs to set their own roadmap, so the KEP is just a template so that SIGs can plan ahead to the completion of the feature and SIG-PM and coordinate with other SIGs. + +Q: How do you submit a KEP? +A: It should live in source control. Each KEP will releate to dozens or hundreds of issues, we need to preserve that as history. + +If you look at the community repo, there's a draft KEP template in process. We need to make it a discoverable doc. diff --git a/events/2017/12-contributor-summit/feature-workflow.md b/events/2017/12-contributor-summit/feature-workflow.md new file mode 100644 index 00000000..8bb0fa47 --- /dev/null +++ b/events/2017/12-contributor-summit/feature-workflow.md @@ -0,0 +1,85 @@ + +Feature Workflow +---------------- + +Notes by @jberkus + +TSC: Getting something done in Kubernetes is byzantine. You need to know someone, who to ask, where to go. If you aren't already involved in the Kubernetes community, it's really hard to get involved. Vendors don't know where to go. + +Jeremy: we had to watch the bug tracker to figure out what sig owned the thing we wanted to change. + +TSC: so you create a proposal. But then what? Who needs to buy-in for the feature to get approved? + +Dhawal: maybe if it's in the right form, SIGs should be required to look at it. + +Robert B: are we talking about users or developers? Are we talking about people who will build features or people who want to request features? + +???: Routing people to the correct SIG is the first hurdle. You have to get the attention of a SIG to do anything. Anybody can speak in a SIG meeting, but ideas do get shot down. + +Caleb: we've had some success in the release process onboarding people to the right SIG. Maybe this is a model. The roles on the release team are documented. + +Anthony: as a release team, we get scope from the SIGs. The SIGs could come up with ideas for feature requests/improvement. + +Tim: there's a priority sort, different projects have different priorities for developers. You need a buddy in the sig. + +Clayton: review bandwidth is a problem. Review buddies hasn't really worked. If you have buy-in but no bandwidth, do you really have buy-in? + +TSC: The KEP has owners, you could have a reviewer field and designate a reviewer. But there's still a bandwidth problem. + +Dhawal: many SIG meetings aren't really traceable because they're video meetings. Stuff in Issues/PRs are much more referencable for new contributors. If the feature is not searchable, then it's not available for anyone to check. If it is going to a SIG, then you need to update the issue, and summarize the discussions in the SIG. + +TSC: Just because a feature is assigned to a SIG doesn't mean they'll acutally look at it. SIGs have their own priorities. There's so many issues in the backlog, nobody can deal with it. My search for sig/scheduling is 10 different searches to find all of the sig/scheduling issues. SIG labels aren't always applied. And then you have to prioritize the list. + +???: Test plans also seem to be late in the game. This could be part of the KEP process. And user-facing-documentation. + +Robert B: but then there's a thousand comments. the KEP proposal is better. + +???: The KEP process could be way to heavy-weight for new contributors. + +???: new contributors should not be starting on major features. The mentoring process should take them through minor contributions. We have approximately 200 full-time contributors. We need to make those people more effective. + +TSC: even if you're a full timer, it's hard to get things in and get a reviewer. Every release, just about everything that it's p0 or p1 gets cut, because the person working on it can't get the reviewer all of the stuff lined up. + +Caleb: you need to spend some time in the project before you can make things work. + +Dhawal: is there a way to measure contributor hours? Are people not getting to things because people are overcommitting? + +Jago: The problem is that the same people who are on the hook for the complicated features are the people who you need to review your complicated feature. Googlers who work on this are trying to spread out their own projects to that they have more time at the end of the review cycle. + +Jaice: If you're talking about a feature, and you can't get anyone to talk about it, either the right people aren't in the room, or there just aren't enough people to make it happen. If we do "just enough" planning to decide what we can do and not do, then we'll waste a lot less effort. We need to know what a SIG's "velocity" is. + +Connor: the act of acquiring a shepard is itself subject to nepotism. You have to know the right people. We need a "hopper" for shepherding. + +Tim: not every contributor is equal, some contributors require a lot more effort than others. + +Robert: A "hopper" would circumvent the priority process. + +Josh: there will always be more submitters than reviewers. We've had this issue in Postgres forever. The important thing is to have a written, transparent process so that when things get rejected it's clear why. Even if it's "sorry, the SIG is super-busy and we just can't pay attention right now." + +Dhawal: there needs to be a ladder. The contributor ladder. + +TSC: a lot of folks who work on Kube are a "volunteer army." A lot of folks aren't full-time. + +Caleb: there is a ladder. People need to work hard on replacing themselves, so that they're not stuck doing the same thing all the time. How do you scale trust? + +???: Kubernetes is a complicated system, and not enough is written down, and a lot of what's there we'd like to change. It's a lot easier for a googler to help another googler, because they're in the same office, and the priorities alighn. That's much harder to do across organizations, because maybe my company doesn't care about the VMWare provider. + +Jaice: for the ladder, is there any notion that in order to assend the ladder you have to have a certain number of people you shepherded in? There should be. + +TSC: frankly, mentoring people is more important than writing code. We need to bring more people into Kubernetes in order to scale the community. + +Josh: we need the process to be documented, for minor features and major ones. Maybe the minor feature process belongs to each SIG. + +Jaice: the KEP is not feature documentation, it's process documentation for any major change. It breaks down into multiple features and issues. + +???: The KEP needs to include who the shepherds should be. + +Clayton: reviewer time is the critical resource. The prioritization process needs to allocate that earlier to waste less. + +Jeremy: the people we sell to are having problems we can't satisfy in Kubernetes. We have a document for a new feature, but we need every SIG to look at it (multi-network). This definitely needs a KEP, but is a KEP enough? We've probably done too much talking. + +Clayton: the conceptual load on this is so high that people are afraid of it. This may be beyond what we can do in the feature horizon. It's almost like breaking up the monolith. + +Robert: even small changes you need buy-in across SIGs. Big changes are worse. + +Connor: working groups are one way to tackle some of these big features. diff --git a/events/2017/12-contributor-summit/kubernetes-client-libraries-open-space.md b/events/2017/12-contributor-summit/kubernetes-client-libraries-open-space.md new file mode 100644 index 00000000..d23327d2 --- /dev/null +++ b/events/2017/12-contributor-summit/kubernetes-client-libraries-open-space.md @@ -0,0 +1,68 @@ +_Notes from the open space discussion at the Kubernetes Contributor Summit 2017 lead by @brendandburns_ + +Three high-level topics: + +* Client libraries and autogeneration +* OpenAPI description status +* Fluent libraries (ie. those with native sensibilities) - is this scalable given need for lots of hand-written code? + +Early shout-out for the [Common LISP client](https://github.com/brendandburns/cl-k8s) :) + +Currently Java, Python, .Net, Javascript clients are all silver. Reference to the [badge and capabilities descriptions](/contributors/design-proposals/api-machinery/csi-new-client-library-procedure.md#client-capabilities) +Python still outside the [clients org](https://github.com/kubernetes-client/) - should this move from incubator? + +Lots of code in client libraries to handle limitations in OpenAPI 2, some of which is fixed in 3. What is required/should we move to OpenAPI 3? + +The Go client is a special case, predates the swagger work and bypasses the autogeneration. This leads to it being an odd first-class citizen. + +Noted that currently client libraries generated against specific version of API +> “I can’t currently write a library which supports multiple versions of the API from the same client” + +Discussion of packaging. Should clients be packaged as one thing (with support for multiple versions in subpackages) or with each package representing support for a specific version? + +Autogeneration is desirable, given the wide number of languages. But what should be the canonical description. Noted that +go-restful, which is currently in use, (starts from Go) vs go-swagger (which starts from an OpenAPI description), worthwhile discussing which mode would work best now. + +Would it be possible to annotate the Go types to avoid some problems in the generator code? + +The API documentation is currently poor, mainly non-language specific API documentation. + +What kind of examples do we expect for each client? It would be great to create a set of canonical usecases for clients and for each of them to have (maybe autogenerated) examples for each. + +There are some Client Guidelines, @mbohlool would have a link? + +Note that the websockets protocol is under-documented. Kubernetes Java client has a description of the protocol and is the best place to look for details. + +SPDY still in use. Should this be deprecated? + +Question about what additional clients, or improvements, people would like to see: +* A smaller Go client +* Rust +* C++ + +Informers, should this be part of the API and available so as to be easier to use from other languages? This is not currently part of the client capabilities set mentioned above. We’re probably better off building a generic multiwatch controller than supporting the informers in all other client libraries. + +Service Catalogue and other extension points. Advice is to use the generator tools to generate your own clients. See [kubernetes-client/gen](https://github.com/kubernetes-client/gen) + +There is a plan to split the go client in to two - one hand rolled, one autogenerated. + +API supports proto as a wire format, but client generation here is hard. The protocol doesn’t know the path to which it needs to be sent. Protos are also generated from the Go structs. + +At least have a common language for description APIs. Proto vs Go. + +Worth noting that kubernetes-client is actually relatively low barrier to entry for getting started contributing to Kubernetes. We should talk about that more publicly. + +Discussion of issues with kubeconfig. + +* There is no spec for kubeconfig? +* One proposal, move folks to kubeconfig.d (ie. one config file per cluster) +* No clients support (apart from Go) support merging kubeconfigs. +* Problem with changes here is the large number of kubeconfigs in existence. +* Can we have a new config file format (v2) which exists alongside the existing one. + +Noting that kubeconfig contains several things, which arguably shouldn't be as closely coupled. + +* Identities +* List of clusters +* Namespace +* Current context diff --git a/events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md b/events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md new file mode 100644 index 00000000..ddb6d688 --- /dev/null +++ b/events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md @@ -0,0 +1,232 @@ +Onboarding Developers through Better Documentation + +@ K8s Contributor Summit, 12/5 + +Note Taker: Jared Bhatti ([jaredbhatti](https://github.com/jaredbhatti)), Andrew Chen ([chenopis](https://github.com/chenopis)), Solly Ross ([directxman12](https://github.com/DirectXMan12)) + +[[TOC]] + +### Goal + +* Understand how we’re currently onboarding developers now + +* Understand the "rough edges" of the onboarding experience for new users + +* Understand how we can better target the needs of our audience + +* Understand if our contributor process will meet the documentation needs. + +Note: the focus is on documentation, so we won’t be able to act on suggestions outside of that (but we will consider them!). + +### Initial thoughts + +* Where we were at the beginning of the 2017: ([@1.4](https://v1-4.docs.kubernetes.io/docs/)) + +* Where we are now: ([@ 1.8](https://kubernetes.io/docs/home/)) + + * We are tied into the launch process + + * We have analytics on our docs + + * We have a full time writer and sig docs contrib group + + * Everything is in templates, we have a style guide + + * Better infrastructure (netlify) + +### Meeting Notes + +* Introductions + + * Jared: SIG docs maintainer + + * Andrew: SIG docs maintainer, techwriter + + * Radika: 1.8 release team, SIG docs member + + * Phil Wittrock: interested b/c it determines how system is used + + * ?? + + * Paul Morie: interested b/c hit challenges that could be avoided with better dev docs (patterns used in Kube can’t be easily found on internet) + + * Nikita: work on CRDs + + * ??: docs are a good intro to core Kube codebase + + * Michael Rubin + + * ??: dashboard contributor, onboarding is a key part of the dashboard experience + + * Steve Wong: storage SIG, on-prem SIG, trying to get head around on-prem, docs geared towards cloud + + * Solly Ross (@directxman12): want to avoid changes to fiddly bits confusing people + + * Morgan Bauer: had issues with people changing fundamental bits out from under other contributors + + * Sahdev Zala: docs are important for new contributors, first place they look, contribex + + * Brad Topol: like explaining stuff, kube conformance WG + + * Tomas: working on side project, looking for inspiration on docs for that + + * Garrett: ContribEx, looking to reduce the question "how do I get started" + + * Stefan (@sttts): where do we push docs changes to mechanics + + * Josh Berkus: ContribEx + +* contributor docs + + * Avoid the process for finding which of the 49 people have the right info 6 months after it merges + + * Have contributor docs which merge with "internal features" (e.g. API registration changes) + + * Have a flag for internal release notes, bot which checks + +* Issue: opinion: we don’t want to write dev docs because they’ll change + + * Issue is it’s hard to capture every little thing + + * Good start is documentation on generalities (80%/20%): e.g building an API server + + * Started out with no docs on how to do that (has gotten better) + +* Big concepts don’t change a lot, describe those + + * Ask questions: + + * What are the big nouns + + * What are the big verbs for those nouns + + * How are the nouns relate + + * Don’t fall into trap of (for example) tracepoints (accidentally creating a lot of small little fiddly points) + +* Need a way for "heads up this is changing". If you have questions, ask these specific people. + + * Very SIG dependent (some do meetings, others mailing-list focused, some have a low bus number) + +* How is your SIG interacting with docs + + * Service Catalog + + * In docs folder + + * How do we interact with docs + + * Depends on moving into kubernetes org + +* Issue: lots of docs with bits and pieces + + * Not organized into "as a developer, you’re interested in these links" + + * Spend a week, come up with a ToC + + * Many docs in different repos + + * Should have guidelines on where to put things + + * Should have templates for how to write different types of docs + +* Issue: wrong abstraction layers are exposed + + * Documenting a complex system has less payoff than simplifying + +* Issue: extending Kube blurs the line between contributor and user + + * Put more docs into the same place + + * "Crafting User Journeys": user stories buckets: Customer User Journeys ([project](https://github.com/kubernetes/website/projects/5)) + + * Need champion for different personas + +* Issue: people (e.g. Storage SIG) want to write docs, but they don’t know where to start + + * Both contributors and users, and both (plugin writing, for example, or how to provision storage securely) + + * Templates/guidelines mentioned above may be helpful + + * Talk to SIG docs (SIG docs wants to try and send delagates to SIG, but for now, come to meetings) + +* Question: should there even *be* a split between user and contributor docs? + + * No, but we have historically (didn’t used to have person-power to implement it) + +* Onboarding docs push for 2018 + + * Point people from moment one to start understanding how to contribute (design patterns, etc) + + * How do we organize, make things findable + + * How do we organize allowing people to contribute right now + + * Main site is all user docs right now + + * Starting to look at auto-import docs + + * User journeys project (above) + + * Testing right now + +* Lots of people writing blog posts + + * Any way to aggregate to some of that? + + * Wow to avoid "this doesn’t work anymore"? + + * There is a Kubernetes blog, being migrated under k8s.io + + * People can contribute to the blog for ephemeral stuff + + * We guarantee that k8s.io stuff is updated + + * For blogs, put a "sell-by date" + +* Request: join dashboard conversation + + * How do we link from dashboard to docs and vice-versa + +* Question: where do the docs of tools like kops fit in + + * More broadly hits on Kubernetes "kernel" vs wrapper projects + + * Right now, it’s checked into repo, so it should have docs on the main site + + * Documentation is endorsing, at bit + + * (but why is kops checked into the repo as opposed to other installers) + + * Have a easy way for projects (incubator and main org) to have their own docs sub-sites (e.g. gh-pages-style for the Kubernetes sites) + +### Follow-Ups + +* Suggestion: Presentation on how to structure site, write docs, user studies done, etc (why are Kube docs the way they are) + + * "I want to get started fast" + + * "I want to build the next thing that gives me value" (task-driven) + + * "Something broke, where’s the reference docs" (troubleshooting) + +### Projects In Development + +* Customer User Journeys ([project](https://github.com/kubernetes/website/projects/5)) + +* Revamp of [docs landing page](https://kubernetes.io/docs/home/) + +* Building out a glossary ([project](https://github.com/kubernetes/website/issues)) + +* More doc sprints ([like this one](https://docs.google.com/document/d/1Ar4ploza6zA1JF3YO4e0lzq1RRBWWx8cAZtRQMMEdsw/edit)) + +### Continue participating! + +* Content exists under [Kubernetes/website](https://github.com/kubernetes/website) (feel free to fix an issue by [creating a PR](https://kubernetes.io/docs/home/contribute/create-pull-request/)) + +* Join the [kubernetes SIG Docs group](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + +* Attend the next Kubernetes docs community meeting (Tuesdays @ 10:30am, PST) + +* And join the kubernetes sig-docs slack channel ([kubernetes.slack.com](http://kubernetes.slack.com/) #sig-docs) + diff --git a/events/2017/12-contributor-summit/role-of-sig-lead.md b/events/2017/12-contributor-summit/role-of-sig-lead.md new file mode 100644 index 00000000..54e3d26f --- /dev/null +++ b/events/2017/12-contributor-summit/role-of-sig-lead.md @@ -0,0 +1,110 @@ +# What is the role of a sig lead +*Notetaker: @MHBauer* +Lots of sig leads are present in the room + +If there is a doc it’s years out of date + +Joe wants to redefine the session +Power and role of sig leads is defined in how we pick these people. Voting? Membership? What do we do for governance in general + + +Paul: Roles that are valuable that are not sig lead. Svc cat, moderator of discussions and took notes. Secratary of committee. + +Back to joe; what does the sig think. Each leader doesn’t know. Who shows up to a meeting isn’t helpful as not everyone can attend. What does the lead thing? Allows too much personal power. Decision maker or tech lead? + +Meeting form last year is that sig lead was facilitator. Have been more tech leads now. Sig leads got invites to the contributor summit. + +Erik from testing. Failures in tests associated with a sig lead to no accountability by a sig member. Assigned the label to the sig with no action afterwards. Need accountability from the sigs or the leads to get testing failures cleared + +Owners files, maintainers, approvers, of particular parts of the code base. As a sig lead. Mostly doing facilitating, and not touching the code. Owners files own the codebase. Not the leads of the sigs. Sig leads elevate problems to the people in the owners files. + +Daniiel smith - api - would not be helpful to have a facilitator, mostly very technical details. + +Paul, tech vs facilitator fulls you in different directions. Facilitator with an agenda is a dictator. If you have a tech agenda, you should not try to lead all the meetings. Meeting facilitator role that aaron did, operated the meeting agenda. Hands to talk. Stopped advocating for techical topics, and mainly doing moderation. Everyone else focuses on technical topics. + +Joe - 3 roles, process facilitatior, technical facilictator, techincal design and lead. Implication that the process leader is not technical. Build consensus vs “we’re doing it this way” + +Down - on sig node. Facilitatior and tech lead. Detach from. If she doesn’s make the agenda there is not one. + +Joe -need someone who cares + +Eric chang - every sig needs a person doing X,Y, Z. docs, tests, etc. fundamental goals. Sig lead has too much to do. Formalize roles and fill them with people, especially different people for each role. +Large sigs have more people to allocate to alt roles. + +Jessie - Can’t have the person who facilitates be unbiased techincally. Best solution vs alternative monetary gain. + +Joe - people as sig leads in name only to game the system as being important + +Erik - adding or retiring members. + +Do any sigs have an election process? Not that we know of. Sig node has a rotation. One member retired as they moved from working on the open source to working on their internal system. Some people turned down a lead, based on the involvememt necessary. + +Sig leads should already should be fulfilling the role, vs assigning titles and duties to expect + +Define roles, and all sigs must provide names. + +Document process for how to choose role. Fair and equitable. A generic process that’s generic. + +People in the sig decide. Who’s in the sig? How do we say a sig or sig member is doing a bad job? + +How to decide who gets to decide? + +Which things does a sig own. People own things, not sigs. With a document proposed to assess new owners. Subteams and persons. + +People who have non-code duties, but are also still participants and lead-worthy. + + Does sig-pm write any code? + +Long term sigs own artifacts. They own process and have long term documentation. + +Things not in kubernetes/kubernetes don’t have necessarily an ownersfile. + +Everything should role up to a sig. + +Owners cut across a project and end up having a person with lots of power vs a sig. + +Sigs and humans as owners. + +Erik f - Tests assigned to owners seems to be a fialure. A sig having a dashboard seems successful. The sig being responsible seems successful, not a person responsible. Things assigned to sigs, not to people. + +Suggestion of a person on a single sig. Limits. Pick what you find important, commit to it. +Might be career limiting if you can olnly work on one thing. +Doubts of same person leading multiple sigs. +Leading a sig vs participating. +Multiple roles again. + +Sig lead, to facilitate, sig pm representative to put technical demands and objectives to the wider community. +What to do when they fail? +Separation of powers. Do we have it now? Are the people who lead a meeting the people who code and merge and approve. + +Joe - gut check summary +Set of roles to nominate +Clear lines of sight which owns what code +Some are large and may have subdivisions (do people own code or do groups) +Starting point for sigs +Everyone should document the process and how it got that way +Possible future date to reboot the sigs. Evolution vs revolution. Merge and split. +Sig lead retired in frvor of multiple roles. “Lead” creates perverse incentives. Roles with terrible titles. POLITICS! + +Find a set of roles. + +What’s the bar to form a sig? +If I want to have a component, I need a sig! + +Retire and merge some sigs. Sig for each cloud and a common cloudprovider and a cross-cloud sig. +Cluster-lifecycle plus cluster-ops + +Daniel - avoid selecting process followers, not for decision making skills. Avoid over specifying. + +Joe - We need to expect some responsibility from the sig to the rest of the project. Avoid overfit. + +Associate owners files with sigs, maintainers vs sig leads. Contributor ladder is disorganized. Owners contributors maintainers. + +4 minutes. +Work with the steering committee to work this out. Steeering committee has to do this to help this make. + +Hard to participate in some sigs, +Suggestion of office hours + +Spotty communication of what a sig is doing. Authority and responsibility of what to communicate what a sig is doing. + diff --git a/events/2017/12-contributor-summit/scaling-new-contributors.md b/events/2017/12-contributor-summit/scaling-new-contributors.md new file mode 100644 index 00000000..925e18ac --- /dev/null +++ b/events/2017/12-contributor-summit/scaling-new-contributors.md @@ -0,0 +1,61 @@ +# Scaling New Contributors +*Lead: Vishnu Kannan* +*Notetaker: Chris Love* + +New pull requests are plateauing in k/k +Takes much longer for a PR to get through + +Contributor Experience +3 mo for PR merged - minor PR that was a fix +Nobody reviewed - was ignored +PRs are lacking process to get them on milestones +Lack of organization and understanding PR process +There is a need for a sig buyin +We have a explicate state machine, instead of a implicate state machine +We do have a well defined process for new contributors to follow +We need to have committed resources to a PR, +File an issue first, then file a PR +When the needs sig is there, the issue will be processed and you can find out which sig + +What is the problem +No time to review PRs + +Mentoring Program +Mentoring program overview +Common theme is that we do not have time to review PR +Bootcamps for new contributors + +Lot of Common Complaints + +Tests did not pass what happened +Devstats +Everyone needs to look at the stats +We are currently bottlenecked at approvers not reviews + +How to fix the problem +SIG Leads are too busy +Have another role within the sigs for mentors +Can we label the issues in terms of complexity +Sig-cli has it documented in a contributor guide +Incentivizing mentoring +How do we help take the load off of the approvers pool, how do we improve reviews +How many times a reviewer say lgtm +Reviewer performance +We need to document what a good review looks like +Guidance on progress to contributor -> reviewer -> maintainer +How does maintain a good citizenship in the community +Put the documentation into kubernetes.io +Simple use-case examples on how to get a PR in +Give contributors some responsibilities +Planned workshop on how to get a PR merged +Contributor based workshop +Ask questions on #kubernetes-dev +We need to document how to get answers +We need to move our documents into kubernetes.io +Sigs may not want to have new contributors +We need to cleanup those who are inactive in k/k - OWNERS and MAINTAINERS +How do we create incentives? +If they are autosigned an issue and do not respond - we need to measure that metric +How do we fix the release process in terms of what is in a release, because we do not have a target we do not know what we are shooting at +We need to figure out what new contributors are working on +Start off by using kubernetes then become contributors diff --git a/events/2017/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md b/events/2017/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md new file mode 100644 index 00000000..d7f3e3a0 --- /dev/null +++ b/events/2017/12-contributor-summit/scaling-up-and-scaling-down-and-addon-management.md @@ -0,0 +1,104 @@ +# Scaling Up & Scaling Down & Addon Management Session… + +Notes by @justinsb + +## Scaling Up & Scaling Down + +Lots of users that want to run on a single node cluster - one node, one core +thockin’s position: 1 node 1 core should continue to work (with 3.75GB, but ideally less than 2GB) +Works today but only just - e.g. you only have 0.2 cores left today +Addons / core components written with a different target in mind +Some of the choices not optimal for single node (e.g. fluentd / ES) + +Cluster Proportional Autoscaler tries to solve this + Targets a daemonset / deployment and changes number of pods + +CPVPA Cluster Proportional Vertical Pod Autoscaler + Applies a step function based on the number of cluster cores to change the resources needed by a target deployment / daemonset +Prototype being used today in GKE for calico + Needs a pod per target which leads to higher resource usage + Idea: to have a single pod that uses a CRD to amortize the costs across multiple targets + Problems we want to address: + We want more granularity at the low end, both because it matters more proportionately + We want to avoid constant rescaling - changing resources requires restarting pods + +Q (solly): What is missing from kubernetes today - what is different vs generic HPA/VPA? Why can’t I reuse the existing HPA/VPA? How do I tell the difference from a UI perspective? +A (thockin): We could wrap the autoscaler; or we could have a ref pointing back up; or we could integrate back into HPA/VPA. The third option is mostly what we’ve encouraged - where things are proved out of tree and then merged back in. + +Some changes needed in HPA/VPA - pulling in metrics from a different source e.g. number of cores in cluster. (Do we need a “count” API) + +Q (clayton): Does this indicate that requests / limits are “broken”? Should we instead be thinking about e.g. overcommit to deal with smaller sizes. +A (thockin): No - the step function is defined by the author of e.g. kube-dns based on their knowledge of the requirements. And this is typically for “fundamental” components, not user applications, and so the broader question for users is separate. + +Q (gus): We need to consider architectures (e.g. 64 bit might use more memory). Are we wasting more memory running a pod to right-size the other pods? +A (thockin): That’s why we want one pod with a CRD, but yes … we want to fold it back in. but we have to prove it first. + +Q: Why can’t this be done in e.g. kubeadm +A: Because clusters change size - e.g. cluster autoscaler + +Q (jago): Focusing on small clusters - we should come up with clear guidance for resource requirements. Maybe we need T-shirt sizes which helps us figure out what we can run in various clusters. +A (thockin): We need to start collecting data - that’s part of this effort. + +Q (vish): Is kubernetes the right approach for small clusters +A: Yes! Yes! Yes! Lots of resounding yeses - devs want to run on their laptops, people happily run personal clusters on single nodes etc. + +Q (dawn): It is hard to come up with a single scale function - e.g. with docker on the node team the kernel options have a big impact. But we should still provide a scaling function as a guide, and to allow for operators to tweak it + +Q (chrislovecnm): Key point - we must collect data! + +Q: There is a lack of documentation on resource requirements e.g. memory requirements of apiserver at various sizes. + + +## Add-on Management + +It’s been the can that’s been kicked down the road +Questions: + What is an addon? + Kubeadm says kube-dns, kube-proxy + GKE adds dashboard & heapster + +Thockin: Addons are things we manage vs things you manage. We = administrator, you = User + +Luxas: kubeadm installs minimal addons to get conformance to pass + +solly: Important not to conflate addons with discussion of what is core vs not + +Clayton: Is Istio an addon? What if it becomes super-complicated... + +Mrubin: 3 categories of addons: + Istio, Service Catalog, Service Broker + Network policy + Kube-proxy and kube-dns +Sniff test: Does it have to be tied to a version of kubernetes? + +Robertbailey: Maybe addons should be the minimal set of things required to pass conformance + +Chrislovecnm: What’s our goal - we want something to install a manifest on the cluster? + +Clayton: the challenge isn’t installation - it’s upgrades / updates. Are we really ready to manage this? Addons should be things that we can actually manage, including addons. + +Thockin: we want a simple solution, not a full solution for arbitrarily complicated applications. + +Jago: We want a set of components that as a platform operator we install and upgrade/version together and validated together, and cluster-level. This is distinct from user applications or even application etcd. + +Bboreham: cross-grade between alternatives is a related aspect - e.g. swap out implementation of network policy. In practice today you have to reinstall the cluster, because otherwise it requires the network policies to cooperate. + +Clayton: comparison to runlevels - where it’s very possible to brick your cluster by doing things out of sequence. + +Gus: The installation tools do all differ in what addons they are installing (e.g. AWS and GCE have very different requirements). So the installation tool will have opinions here - what value are we adding? + +Thockin: There is an opportunity here to define something cross-cutting - “apt or yum for kubernetes”. Having each installer do something different is not great. + +Clayton: apt or yum doesn’t get you all the way - you still need to tweak configurations. + +Mrubin: Kubernetes is a bunch of small pods cooperating. The mechanism is the same for installing DNS as it is for network policy - which is good in that we have a harmonized approach. We want to figure out the mechanism by which components can be packaged by authors, discovered, and integrated by installers. + +Mrubin: There is a belief that some pods in kube-system are special + +Dawn: The kube-system namespace is known to be system-managed / updated and critical pods - even if it isn’t actually special in a technical sense. + +Jess: We want to avoid decision paralysis. And there’s odd incentives where people want to monetize their code or their approach. We have to limit the scope as much as possible. + +Robertbailey: Agreed - we have to scope this just to the minimal components needed to install stuff. And then users can install more opinionated things like helm. + +Thockin wrapping up: Still an open question of what we should do here, how the various distributions should avoid duplicating effort. diff --git a/events/2017/12-contributor-summit/schedule.png b/events/2017/12-contributor-summit/schedule.png new file mode 100644 index 00000000..03942e5d Binary files /dev/null and b/events/2017/12-contributor-summit/schedule.png differ diff --git a/events/2017/12-contributor-summit/should-k8s-use-feature-branches.md b/events/2017/12-contributor-summit/should-k8s-use-feature-branches.md new file mode 100644 index 00000000..f8af5427 --- /dev/null +++ b/events/2017/12-contributor-summit/should-k8s-use-feature-branches.md @@ -0,0 +1,113 @@ +# Should Kubernetes use feature branches? + +Lead: Brian Grant + +Note Taker(s): Aaron Crickenberger + +Focusing on our current release cadence: + +- We spend several weeks putting features in +- We spend several weeks stabilizing the week kinda/sortof + +The people who are managing the release process don’t have the ability to push back and say this can’t go in and we don’t want to slip the release so they’re left powerless + +In earlier session today over breaking up monolith: + +- We have over 90 repos +- The releases are getting bigger and more complex +- Not everything we’re moving out of the monorepo, not everything makes sense + +What do we do about those things +I think the only way we can get out of the release fire drills is to have an earlier gate + +Q: Aaron: Why not use the tests we have today and push back saying the tests have to be green? + +- A lot of the new features have inadequate testing or inadequate features +- We want to continue to release on a regular on cadence +- Use some model like gitflow that puts feature work into feature branches before they land into master +- I think we need to allow features to be developed in feature branches instead of landing in kubernetes/kubernetes master +- But we also can’t have large monolithic feature branches +- Because one thing going in might cause rebase hell for other things going in +- Test machinery is getting to a point where it can use branches other than master to spin up tests +- You can spin up a feature branch and get tests running on it without too many issues +- I think we have to do within either 1.10 or 1.11 release + +Q. I heard two 2 concerns: + +- How do you protect mainline development from these features going in? +- How do you know when they’re ready to go in? +- So nodejs claims to have something like 90-something% coverage, we don’t even have coverage measurement +- With the interdependence of everything in the system it’s basically impossible to back changes out + +Q: (thockin) +How do we think we can do this across repos? + +- Can we hear from people who have actually tried this for what the pain points are? +- There are lots of details to work out and people are just going to have to try it at small scale and then at large scale +- A lot of the times people try to get their foot in the door with tiny feature PR’s, and then docs, and then feature completion +- Jan commenting on experience with workload api’s +- Tried bumping workload api’s from v1beta2 to v1, tried it on feature branch +- Main blocker was tests, tests weren’t running against the feature branch, only the master branch automatically +- We decided we were just going to do it directly against the master branch + +Q (spiffxp) How do we prevent merge chicken, aka racing to get in so you don’t have to avoid rebase hell + +- With api machinery, one thing we’ve done is wait until after the release cycle to minimize the amount of time that people have to do rebasing +- We scheduled that massive change to land right after code freeze +- Re: how do we prevent once you’re in you’re in… that’s basically the way it goes right now + +Thockin: + +- the pattern that I see frequently is somebody sends me a 10k line PR and I see please break this up and they do, but then they forget the docs and somewhere along the way we miss it +- Bgrant: it’d be great if we could ask people to write the docs first (maybe this is a criteria for feature branches) +- Venezia: what about having a branch per KEP? Also, facebook does something like feature flags, is that something we could do or is that just impossible? + +Bgrant: + +- That can be used, but it requires a huge amount of discipline to ensure those flags are used correctly and consistently throughout the code +- Some features we can easily do that eg: if it’s an API, but it’s much harder to do with a feature that’s threaded through components +- A branch per KEP is roughly the right level of granularity +- What’s the difference between a feature branch and a massive PR? +- Review flow isn’t well suited to massive PR’s +(thockin) It’s easier on maintainers if we get things in and lock them in, but not on the main tree +(thockin) one thing I like about the linux kernel model is the lieutenant model + +Q: (maru) you’re still going to have to rebase feature branches the way that you rebase PR’s right? + +- A (jago) the difference is that a whole team could work on a feature branch +- I like the idea of trying a few projects and then reporting back +- I think roughly the level of granularity of having a branch per KEP sounds about right +- Multiple feature branches affecting the same area of code would be a very useful place to get some infromation + +Q (???) if someone needs to rebase on a feature branch, could it instead be resolved by a merge commit instead? + +- (thockin) I think we could solve that with technology and it could be better than building a better review tool +- Rebasing sucks, part of the reason we have that is generated code, part of it is poor modularity +- We could stand to expend some energy to improve modularity to reduce rebases +(bgrant) either feature branches or moving code to other repos are forcing functions to help us clean some of that up + +Q: how do we make sure that when issues are filed people know which commit/feature branch they should be filing against? +- (bgrant) I suspect most issues on kubernetes/kubernetes are filed by contributors +- (jdumars) imagine you have a KEP that represents three issues, three icecubes you’ve chipped off the iceberg, the feature branch would hold code relevant to all of those issues +- (luxas) feature branches should be protected + +Yes we’ll definitely want a bot that automatically +Q: (alex) do we want to have feature branches +Q: (thockin) why not just use a fork instead of branches? + +- I think it’s harder to get tests spun up for other users +- (jgrafton) worry about adding yet another dimension of feature branches to our already large matrix of kubernetes and release branches + +- Not so much for PR’s, but for CI/periodic jobs +- You need to run more than just the PR tests +- The experience with gated features is that tests do run less often, so racey bugs that pop up less frequently get exposed less often; so there is a concern that we wouldn’t get enough testing coverage on the code +- We’ll figure out what the right granularity is for feature branches is, probably shorter than a year, but probably shorter than a year +- One idea is instead of support forks to users, what if we forked to orgs owned by sigs, and just made sure the CI was well setup for those orgs? +(ed. I’m nodding my head vigorously that this is possible) +- Just another comment on branches on main repo vs. in other repos +- The branches in the main repo could be another potential for mistakes and fat fingers that we could be better solve by making the tooling work against arbitrary repos +- (jgrafton) related to the ownership of e2e tests and the explosion of stuff.. Do we expect sigs to own their tests across all feature branches? - Or should they only care about master + +Q: worry about tying feature ownership too closely to a single sig, because features could involve multiple sigs + +If you want to get started with feature branches, reach out to kubernetes-dev first and we’ll get you in touch with the right people to get this process started diff --git a/events/2017/12-contributor-summit/steering-committee-update.md b/events/2017/12-contributor-summit/steering-committee-update.md new file mode 100644 index 00000000..3c2f0a92 --- /dev/null +++ b/events/2017/12-contributor-summit/steering-committee-update.md @@ -0,0 +1,47 @@ +Steering Committee Update +-------------------------- + +Notes by @jberkus + +Showed list of Steering Committee backlog. + +We had a meeting, and the two big items we'd been pushing on hard were: + +* votining in the proposals in the bootstrap committee +* how we're going to handle incubator and contrib etc. + +Incubator/contrib: one of our big concerns are what the the consequences for projects and ecosystems. +We're still discussing it, please be patient. In the process of solving the incubator process, we have to answer +what is kubernetes, which is probably SIGs, but what's a SIG, and who decides, and ... we end up having to examine +everything. In terms of deciding what is and isn't kubernetes, we want to have that discussion in the open. +We also recognize that the project has big technical debt and is scary for new contributors. + +We're also trying to figure out how to bring in new people in order to have them add, instead of contributing +to chaos. So we need contributors to do mentorship. We also need some tools for project management, if anyone +wants to work on these. + +We're also going to be working on having a code of conduct for the project, if you +want to be part of that discussion you can join the meetings. For private concerns: steering-private@kubernetes.io. +One of the challenges is deciding how enforcement will work. We've had a few incidents over the last 2 years, +which were handled very quietly. But we're having more people show up on Slack who don't know norms, +so feel free to educate people on what the community standards are. As our project expands across various +media, we need to track the behavior of individuals. + +Q: "Can SIGs propose a decision for some of the stuff on the backlog list and bring it to the SC?" +A: "Yes, please!" + +The other big issue is who owns a SIG and how SIG leaders are chosen. The project needs to delegate more things to the +SIGs but first we need to have transparency around the SIG governance process. + +Q: "As for What Kubernetes Is: is that a living document we can reference?" +A: "There's an old one. I have a talk on Friday about updating it." + +There's also the question of whether we're involved in "ecosystem projects" like those hosted by the CNCF. Things will change +but the important thing is to have a good governance structure so that we can make transparent decisions as things change. + + + + + + + diff --git a/events/2017/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md b/events/2017/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md new file mode 100644 index 00000000..b2f202b3 --- /dev/null +++ b/events/2017/12-contributor-summit/whats-up-with-sig-cluster-lifecycle.md @@ -0,0 +1,62 @@ + +What's Up with SIG-Cluster-Lifecycle +------------------------------------ + +Notes by @jberkus + +Luxas talking: I can go over what we did last year, but I'd like to see your ideas about what we should be doing for the future, especially around hosting etc. + +How can we make Kubeadm beta for next year? +Opinions: +* HA + * etcd-multihost + * some solution for apiserver, controller +* Self-hosted Kubeadm + +Q: Can someone write a statement on purpose & scope of Kubeadm? + +To install a minimum viable, best-practice cluster for kubernetes. You have to install your own CNI provider. Kubeadm isn't to endorse any providers at any level of the stack. + +Joe: sub-goal (not required for GA), would be to break out components so that you can just install specific things. +Would also like documentation for what kubeadm does under the covers. + +Josh: requested documentation on "how do I modify my kubeadm install". Feels this is needed for GA. Another attendee felt the same thing. + +One of the other goals is to be a building block for higher-level installers. Talking to Kubespray people, etc. Enabling webhooks used as example. + +There was some additional discussion of various things people might want. One user wanted UI integration with Dashboard. The team says they want to keep the scope really narrow in order to be successful. UI would be a different project. GKE team may be working on some combination of Kubeadm + Cluster API. Amazon is not using Kubeadm, but Docker is. Docker for Mac and Windows will ship with embedded kubernetes in beta later this week. + +Kubeadm dilemma: we want humans to be able to run kubeadm and for it to be a good experience, and for automation to be able to run it. I don't think that can be the same tool. They've been targeting Kubeadm at people, we might want to make a slightly different UI for machines. Josh says that automating it works pretty well, it's just that error output is annoying to capture. + +HA definition: +* etcd should be in a quorum HA standard (3+ nodes) +* more than one master +* all core components: apiserver, scheduler, kcm, need to be on each master +* have to be able to add a master +* upgrades + +Or: we want to be able to survive a loss of one host/node, including a master node. This is different, if we want to survive the loss of any one master, we only need two then. Argument ensued. Also, what about recovery or replacement case? A new master needs to be able to join (manual command). + +What about HA upgrades? Are we going to support going from one master to three? Yes, we have to support that. + +Revised 4 requirements: +* 3+ etcd replicas +* all master components running in each master +* all TLS secured +* Upgrades for HA clusters + +Everyone says that we want a production environment, but it's hard to define what "production grade" means. We need to stop saying that. Over time, what matters is, "is it maintained". If it's still being worked on, over time it'll get better and better. + +CoreOS guy: trying to do self-hosted etcd. There's a lot of unexpected fragile moments. Just HA etcd isn't well tested upstream, there's not enough E2E tests. Self-hosting makes this worse. The etcd operator needs work. There needs to be a lot of work by various teams. Self-hosted control planes work really well, they host all of their customers that way. It's etcd that's special. + +There's some problems with how Kubernetes uses HA Etcd in general. Even if the etcd operator was perfect, and it worked, we couldn't necessarily convince people to use it. + +Should Kubeadm focus on stable installs, or should it focus on the most cutting-edge features? To date, it's been focused on the edge, but going to GA means slowing down. Does this mean that someone else will need to be forward-looking? Or do we do feature flags? + +SIG-Cluster-Lifecycle should also document recommendations on things like "how much memory do I need." But these requirements change all the time. We need more data, and testing by sig-scalability. + +For self-hosting, the single-master situation is different from multi-master. We can't require HA. Do we need to support non-self-hosted? We can't test all the paths, there's a cost of maintaining it. One case for non-self-hosted is security, in order to prevent subversion of nodes. + +Also, we need to support CA-signed Kubelet certs, but that's mostly done. + +So, is HA a necessity for GA? There are a bunch of automation things that already work really well. Maybe we should leave that to external controllers (like Kops etc) to use Kubeadm as a primitive. Now we're providing documentation for how you can provide HA by setting things up. But how would kubeadm upgrade work, then? diff --git a/events/elections/2017/BALLOTS.csv b/events/elections/2017/BALLOTS.csv new file mode 100644 index 00000000..9c67b4c1 --- /dev/null +++ b/events/elections/2017/BALLOTS.csv @@ -0,0 +1,310 @@ +Timothy St. Clair,Ilya Dmitrichenko,Caleb Miles,Doug Davis,Phillip Whitrock,Kris Nova,Derek Carr,Aaron Crickenberger,Jaice Singer DuMars,Michelle Noorali,Ihor Dvoretskyi,Alex Pollitt,Michael Rubin,Quinton Hoole,Rob Hirschfeld,Aaron Schlesinger,Sebastien Goasguen,Matt Farina,Adnan Abdulhussein,Justin Santa Barbara +20,20,10,20,2,20,15,1,1,2,20,20,2,20,20,20,20,15,20,10 +4,20,20,20,6,20,2,20,20,20,20,5,20,1,20,20,20,20,20,3 +7,16,11,11,11,2,10,5,1,2,7,No opinion,15,5,17,11,9,No opinion,No opinion,2 +20,1,20,20,20,20,20,20,20,20,2,20,20,20,20,20,20,20,20,20 +5,No opinion,8,No opinion,3,No opinion,1,7,No opinion,4,No opinion,No opinion,2,6,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +3,20,5,6,7,2,7,7,7,7,7,1,4,16,18,7,14,19,7,17 +1,20,20,20,20,2,20,20,20,3,20,20,20,20,20,20,4,20,20,20 +4,1,20,20,20,20,20,20,20,3,20,20,20,20,20,20,20,20,2,20 +8,13,16,3,2,7,19,15,6,12,5,18,1,20,11,17,4,9,14,10 +20,20,20,20,20,20,1,20,20,20,20,20,20,20,20,20,20,20,20,20 +6,20,8,20,3,13,1,7,12,2,20,9,4,5,20,20,10,20,11,20 +20,20,3,20,9,1,4,7,2,5,20,20,9,9,20,6,20,20,20,20 +20,20,20,20,20,20,1,20,20,20,20,20,20,20,20,20,20,20,20,20 +2,3,8,20,20,5,1,20,20,6,20,20,20,20,7,20,20,9,20,4 +2,14,8,20,3,9,1,7,13,5,18,10,6,4,19,16,11,15,12,17 +20,20,20,6,20,2,20,4,3,1,20,20,20,5,20,20,20,20,20,20 +6,20,8,20,3,20,1,7,20,2,20,9,4,5,20,20,10,20,20,20 +13,No opinion,7,No opinion,1,11,12,5,10,4,6,No opinion,No opinion,2,No opinion,No opinion,8,No opinion,No opinion,3 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +4,20,8,5,7,6,14,14,3,14,14,1,2,17,15,9,18,14,19,16 +2,8,19,20,4,7,1,10,16,9,5,11,3,6,14,15,13,18,17,12 +5,18,16,11,6,1,12,20,17,4,9,8,7,19,13,14,2,10,15,3 +7,3,12,1,5,19,9,16,18,13,2,15,20,10,6,17,8,11,14,4 +1,14,11,12,7,2,3,6,5,4,17,10,9,16,19,No opinion,8,No opinion,15,20 +20,18,11,2,5,17,9,10,7,8,4,14,19,12,16,15,1,3,6,13 +3,20,7,20,2,20,20,10,9,4,6,20,1,20,20,20,12,8,5,11 +2,20,20,20,20,20,1,4,20,20,6,20,5,3,20,20,20,20,20,20 +2,18,5,12,8,6,1,7,16,9,14,15,3,4,20,13,10,17,19,11 +5,20,20,20,3,1,16,20,20,1,20,20,4,6,20,20,20,20,20,7 +20,11,2,20,1,12,5,11,2,9,6,20,1,20,8,11,9,12,11,6 +2,7,2,1,20,20,5,20,20,20,6,20,20,3,20,20,20,20,20,4 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +20,20,20,20,20,20,2,20,1,20,20,20,20,20,20,20,20,20,20,20 +7,12,8,17,3,11,1,6,10,4,18,15,5,2,20,19,13,14,9,16 +12,1,2,8,17,4,9,3,19,10,14,13,18,11,5,15,7,6,16,20 +7,18,20,4,3,14,1,9,12,2,15,8,5,6,19,17,10,16,11,13 +8,18,15,14,1,10,17,12,3,20,11,20,1,16,20,19,2,20,9,13 +6,20,8,20,7,6,3,4,8,2,20,20,1,9,5,20,20,20,20,4 +2,20,20,20,1,20,20,20,20,20,6,20,3,20,20,20,5,20,20,4 +3,20,20,20,2,20,20,20,20,20,20,20,1,20,20,20,20,20,20,20 +4,10,8,20,5,20,1,3,20,20,6,20,2,11,20,9,20,20,20,7 +20,20,1,20,7,3,20,20,20,2,20,4,6,20,5,20,20,20,20,20 +1,5,13,16,10,20,9,11,12,19,14,17,15,2,18,4,7,3,8,6 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +20,20,20,20,20,1,20,20,20,20,20,20,20,20,20,20,20,20,20,20 +20,20,1,20,3,20,20,6,5,2,20,8,4,7,20,20,20,20,20,9 +2,20,9,20,1,20,2,9,2,1,9,20,7,7,20,20,20,20,20,2 +20,20,2,20,20,20,20,5,20,1,3,20,20,20,6,20,20,20,20,4 +2,20,4,20,4,20,1,20,20,3,20,20,20,20,20,20,20,20,20,20 +2,20,20,20,20,20,1,20,19,3,20,20,20,20,20,20,20,20,20,20 +6,9,No opinion,No opinion,No opinion,5,No opinion,No opinion,4,1,2,No opinion,No opinion,No opinion,3,No opinion,8,No opinion,No opinion,7 +19,9,4,20,1,16,5,7,17,18,3,6,2,10,13,15,11,8,12,14 +8,16,18,12,13,6,15,10,4,19,7,3,9,2,5,11,1,14,17,20 +6,14,8,20,4,13,1,7,12,3,18,9,5,2,19,16,10,15,11,17 +20,20,20,20,2,20,4,20,20,20,20,20,1,20,20,20,20,20,20,4 +14,No opinion,3,13,2,12,No opinion,4,1,6,9,No opinion,11,5,10,8,7,No opinion,No opinion,16 +3,No opinion,No opinion,No opinion,No opinion,2,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +1,18,8,10,9,11,4,5,6,3,17,14,12,2,20,13,16,19,15,7 +No opinion,3,No opinion,No opinion,No opinion,20,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,No opinion,No opinion,1,2,5,No opinion,No opinion +13,13,3,18,1,14,9,5,6,10,8,19,2,20,13,15,4,17,11,7 +No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,1 +7,18,11,14,1,9,8,12,5,2,20,4,10,19,17,6,3,13,16,15 +1,4,15,17,15,6,20,15,16,2,5,15,15,3,7,18,15,19,15,15 +20,20,20,20,20,2,20,20,20,5,20,4,3,1,20,20,20,6,20,20 +2,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,6,No opinion,4,No opinion,7,8,No opinion,3,9,No opinion,5 +20,No opinion,2,3,1,20,2,2,5,20,3,5,1,20,No opinion,20,No opinion,3,No opinion,2 +3,No opinion,No opinion,No opinion,1,5,No opinion,No opinion,No opinion,4,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +2,20,20,20,3,4,1,20,20,5,20,20,20,20,20,6,20,20,20,20 +3,11,8,15,2,12,1,7,10,4,13,9,5,6,13,11,9,11,9,14 +4,9,6,20,3,20,1,5,20,20,20,20,8,20,20,20,20,20,20,1 +8,19,11,19,6,5,10,1,3,7,4,19,2,19,19,12,9,19,19,20 +8,No opinion,16,No opinion,2,13,9,3,1,11,10,No opinion,7,4,5,15,14,12,No opinion,6 +3,7,4,20,10,1,2,20,12,9,20,6,5,11,20,20,20,8,20,20 +20,20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20 +5,20,20,20,2,20,3,20,20,7,4,20,1,6,20,20,20,20,20,20 +13,19,17,20,5,6,7,9,1,2,12,18,14,11,16,8,10,4,3,15 +5,20,19,19,19,2,19,19,7,19,8,1,3,19,6,19,19,19,19,19 +3,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20,2,20,20 +4,20,20,20,5,20,2,1,6,20,20,20,20,20,20,20,20,20,20,3 +6,No opinion,8,No opinion,3,No opinion,1,7,No opinion,2,No opinion,9,4,5,No opinion,No opinion,10,No opinion,No opinion,No opinion +2,5,4,7,18,19,6,11,15,14,16,3,1,20,17,9,8,12,10,13 +20,20,1,20,1,1,20,1,1,1,20,20,20,20,20,20,20,20,20,20 +11,5,No opinion,4,3,No opinion,No opinion,9,No opinion,2,20,10,7,No opinion,No opinion,8,6,No opinion,No opinion,1 +2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,1 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +20,20,1,20,3,20,20,6,5,2,20,8,4,7,20,20,20,20,20,9 +2,No opinion,8,13,3,12,1,9,7,4,No opinion,No opinion,5,6,10,No opinion,No opinion,No opinion,No opinion,11 +6,19,3,19,19,7,9,2,1,19,5,19,7,4,19,10,19,19,19,20 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +2,6,13,20,12,5,19,10,19,9,8,14,6,19,7,19,4,1,3,11 +10,10,8,10,1,10,1,10,1,10,1,1,8,20,10,10,1,10,10,1 +8,14,3,12,6,15,1,9,11,5,20,10,2,7,20,20,20,13,20,4 +6,4,5,13,7,1,17,17,10,3,11,8,17,18,20,9,17,19,12,2 +5,14,7,20,2,13,1,6,12,8,18,9,3,4,19,16,10,15,11,17 +4,18,20,18,1,19,14,17,2,18,13,18,15,18,12,18,16,18,18,3 +2,9,20,20,11,5,8,3,4,6,10,20,20,20,7,12,11,20,20,1 +13,7,11,16,1,20,3,6,5,19,14,9,4,17,15,12,8,10,18,2 +1,20,20,20,20,2,20,20,20,3,20,20,20,6,20,4,20,20,20,5 +4,14,7,20,3,12,1,8,19,2,18,10,6,5,16,17,15,11,9,13 +No opinion,5,2,No opinion,No opinion,4,No opinion,No opinion,2,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion +20,20,20,20,2,20,20,20,20,20,20,20,1,20,20,20,20,20,20,20 +6,10,7,12,5,16,3,13,19,9,8,11,2,1,18,20,15,17,14,4 +6,3,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,7,No opinion,1,5,No opinion,No opinion,No opinion,No opinion,No opinion,4 +20,20,5,20,1,20,5,2,4,20,20,20,3,20,20,20,20,20,20,5 +3,20,8,20,4,20,1,20,20,5,20,20,2,7,20,20,20,20,20,6 +7,5,20,15,4,17,10,1,6,3,9,18,2,13,16,19,11,14,8,12 +4,7,No opinion,No opinion,No opinion,3,No opinion,6,8,2,9,No opinion,No opinion,5,No opinion,No opinion,No opinion,No opinion,10,1 +20,20,20,20,20,1,20,4,20,2,8,5,3,20,20,7,20,6,20,20 +18,16,15,20,5,2,17,19,9,1,3,11,10,12,13,7,4,8,6,14 +2,12,14,15,8,3,7,13,4,1,5,18,16,19,17,6,11,20,9,10 +3,20,4,20,1,20,1,2,2,20,2,20,1,20,20,20,20,20,20,2 +4,17,5,14,18,1,11,8,10,2,3,19,20,7,6,9,16,15,13,12 +5,10,10,20,2,5,3,20,10,5,10,20,1,10,20,20,20,10,20,5 +6,20,8,20,3,20,1,7,20,2,20,9,4,5,20,20,10,20,20,20 +3,20,5,20,9,20,1,7,20,8,20,20,2,20,20,20,20,20,20,4 +7,20,8,20,20,20,3,4,6,20,20,20,1,5,20,20,20,20,20,2 +20,20,20,3,7,4,20,5,2,20,6,20,20,20,20,20,20,20,20,1 +3,20,5,14,10,7,13,1,4,6,12,8,9,20,20,20,11,2,20,20 +11,2,18,20,16,3,10,17,1,7,19,12,15,5,14,4,13,9,6,8 +5,20,7,20,1,20,4,20,20,2,20,20,20,3,20,20,20,20,20,6 +15,No opinion,6,13,1,No opinion,14,3,4,10,7,No opinion,2,12,No opinion,No opinion,7,7,No opinion,5 +15,14,12,8,16,11,1,19,17,20,4,10,3,13,9,5,18,7,6,2 +7,19,10,10,1,20,9,11,16,3,18,6,2,4,8,13,5,15,14,17 +3,5,10,13,2,9,4,20,6,12,15,16,1,14,11,8,18,19,7,17 +3,18,5,20,12,6,1,10,13,2,14,8,7,4,16,17,9,19,11,15 +20,20,4,20,2,20,8,7,3,20,6,20,1,20,20,20,20,20,20,5 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,2 +8,12,7,No opinion,4,11,1,13,3,10,6,No opinion,2,9,No opinion,14,No opinion,No opinion,No opinion,5 +2,20,8,20,11,20,1,20,9,7,20,20,6,5,12,4,10,20,20,3 +20,19,8,17,1,10,17,17,17,10,11,17,2,7,17,3,7,10,18,7 +20,20,20,20,1,20,5,4,20,20,20,20,3,6,20,20,20,20,20,2 +4,7,6,20,11,3,15,10,19,1,13,8,14,16,12,5,17,2,9,18 +19,20,20,20,20,20,20,20,20,20,1,2,20,20,18,20,20,20,20,20 +No opinion,No opinion,19,No opinion,12,18,15,20,11,10,13,No opinion,16,No opinion,14,17,8,No opinion,No opinion,9 +4,14,7,20,3,12,1,18,13,2,10,8,6,5,19,17,9,15,11,16 +2,20,20,20,20,20,1,20,4,20,20,20,3,20,20,20,20,20,20,5 +4,No opinion,3,12,6,15,13,11,10,13,10,20,2,18,5,10,1,10,10,14 +1,2,20,20,20,2,20,20,20,20,20,20,20,3,20,20,20,20,20,20 +20,16,17,19,8,18,6,2,4,5,3,12,9,10,15,14,13,1,7,11 +6,No opinion,11,No opinion,13,1,4,No opinion,3,2,5,No opinion,8,No opinion,No opinion,10,12,No opinion,9,7 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +17,20,18,20,2,20,5,18,18,10,4,20,1,3,20,18,7,20,20,6 +7,4,7,7,7,2,7,7,7,7,3,7,6,5,7,7,7,7,7,1 +6,9,9,4,6,1,7,8,4,2,10,7,5,5,9,10,8,5,3,6 +4,No opinion,No opinion,1,3,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,5,No opinion,No opinion,No opinion,No opinion +6,11,8,20,3,10,1,7,9,2,14,13,4,5,15,18,16,17,12,19 +11,No opinion,No opinion,No opinion,9,1,No opinion,No opinion,No opinion,7,6,8,5,10,4,No opinion,3,No opinion,12,2 +20,20,4,20,1,20,20,20,20,20,20,20,1,6,20,20,20,20,5,20 +14,1,13,12,7,20,6,8,1,15,16,4,3,5,2,10,19,17,11,9 +5,6,No opinion,No opinion,No opinion,1,No opinion,No opinion,4,2,5,5,No opinion,No opinion,4,3,No opinion,No opinion,No opinion,3 +19,6,4,20,8,13,7,11,10,9,14,2,1,20,3,17,12,15,16,5 +11,6,9,20,4,2,3,12,10,8,5,13,20,20,20,20,20,20,7,1 +3,20,4,20,7,4,20,1,20,20,4,20,20,20,20,8,20,2,20,20 +14,1,5,No opinion,6,3,11,2,7,9,10,No opinion,15,8,12,No opinion,4,16,13,No opinion +6,20,20,20,20,2,20,17,7,3,20,20,20,18,20,20,20,18,20,18 +5,10,9,17,6,20,15,2,1,4,11,15,8,12,18,3,8,15,16,19 +3,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,8,4,No opinion,No opinion,2,6,No opinion,No opinion,7,No opinion,No opinion,5 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +7,20,9,20,2,5,1,8,10,3,20,20,6,4,20,20,20,20,20,20 +6,14,8,20,3,12,1,7,13,2,19,9,4,5,17,18,10,15,11,16 +2,No opinion,No opinion,No opinion,No opinion,5,3,No opinion,7,6,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,No opinion,No opinion,1 +11,No opinion,10,No opinion,4,No opinion,1,2,8,5,13,No opinion,6,7,No opinion,No opinion,9,3,12,20 +12,14,1,20,7,15,4,3,9,10,11,5,6,18,19,16,2,8,17,13 +2,16,13,19,7,6,11,17,9,5,18,20,1,12,10,15,3,14,4,8 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +5,No opinion,No opinion,3,No opinion,2,1,No opinion,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +1,6,18,16,4,3,2,17,5,No opinion,19,No opinion,No opinion,6,No opinion,No opinion,No opinion,No opinion,No opinion,20 +20,11,7,6,1,16,3,12,5,15,2,18,1,4,19,17,13,14,10,8 +20,20,20,20,2,20,20,20,20,20,20,20,1,20,20,20,20,20,20,3 +9,19,3,2,6,16,10,1,5,No opinion,15,8,14,17,13,12,4,7,11,18 +2,20,20,19,20,5,1,19,19,3,4,20,20,20,20,20,20,19,20,19 +6,14,8,14,3,12,1,7,12,2,14,9,4,5,14,14,9,14,9,14 +2,20,1,20,3,20,20,20,20,20,20,20,20,4,20,20,20,20,20,20 +2,3,3,3,3,3,3,3,3,3,3,3,1,3,3,3,3,3,3,3 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +8,10,18,9,1,20,7,5,13,6,4,11,3,19,14,15,12,16,17,2 +2,8,5,18,1,No opinion,2,19,9,19,No opinion,5,6,19,18,19,20,No opinion,19,1 +3,20,8,20,20,5,20,1,4,6,20,7,20,20,20,20,20,2,20,20 +3,14,7,20,6,13,2,8,12,4,20,10,5,1,20,16,9,15,11,17 +6,20,10,20,3,20,1,10,20,2,20,15,4,5,20,20,15,20,15,20 +10,15,2,11,13,14,1,17,19,18,7,19,6,12,20,9,16,5,4,3 +7,8,10,No opinion,No opinion,11,2,No opinion,5,1,4,No opinion,9,6,No opinion,No opinion,No opinion,No opinion,No opinion,3 +20,20,20,6,2,4,20,20,20,5,20,20,1,20,20,3,20,20,20,20 +5,3,9,4,15,1,17,18,12,2,6,20,19,11,16,7,14,13,8,10 +4,No opinion,1,No opinion,No opinion,2,No opinion,No opinion,No opinion,5,No opinion,3,No opinion,6,No opinion,No opinion,No opinion,No opinion,No opinion,7 +1,11,4,15,5,6,8,9,2,7,20,17,3,10,13,12,19,14,16,18 +5,3,No opinion,No opinion,No opinion,4,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,2,No opinion,6,No opinion,No opinion,No opinion +2,4,20,20,20,20,1,20,20,20,20,5,20,20,20,20,3,20,20,20 +4,20,5,6,12,7,8,11,3,9,14,1,2,18,10,13,17,16,15,19 +20,20,20,20,20,20,2,20,20,20,20,20,20,20,20,20,20,20,20,1 +No opinion,No opinion,No opinion,1,No opinion,No opinion,2,No opinion,No opinion,7,No opinion,No opinion,No opinion,6,No opinion,No opinion,No opinion,3,5,4 +5,20,20,20,20,20,20,20,1,2,20,20,3,20,20,20,20,20,20,4 +11,13,18,3,10,15,6,8,17,4,14,9,7,12,19,20,1,2,5,16 +1,19,19,19,19,4,20,5,2,19,19,19,3,19,19,19,19,19,19,19 +20,19,19,19,19,19,18,17,19,17,19,19,19,19,19,19,19,18,19,19 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +5,18,7,20,3,12,1,8,13,2,18,10,4,6,19,18,11,18,9,18 +2,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +4,5,20,20,20,1,20,20,20,3,20,2,20,20,20,20,20,20,20,20 +3,12,6,17,1,15,13,14,9,5,19,7,2,20,10,18,11,8,16,4 +6,18,8,20,3,18,1,7,18,2,18,18,4,5,18,18,18,18,18,18 +1,No opinion,3,No opinion,No opinion,2,4,No opinion,No opinion,No opinion,No opinion,7,No opinion,5,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +20,20,20,20,20,1,20,20,4,2,20,3,20,20,20,20,20,20,20,20 +10,3,4,No opinion,No opinion,12,No opinion,No opinion,No opinion,8,1,7,No opinion,No opinion,9,No opinion,1,5,6,11 +20,8,12,19,7,18,14,5,1,3,9,16,18,15,17,6,11,2,4,13 +5,15,6,20,12,10,16,7,18,2,1,14,19,17,8,11,13,4,3,9 +10,19,16,3,2,14,5,20,12,17,18,4,1,7,9,8,6,15,13,11 +6,20,5,20,4,20,20,1,8,7,20,20,3,20,20,20,9,2,20,20 +12,16,7,20,1,6,9,5,8,4,14,3,2,18,17,11,13,15,19,10 +8,20,20,20,1,20,3,20,20,4,20,20,2,6,20,7,5,20,10,9 +6,No opinion,No opinion,No opinion,2,No opinion,No opinion,20,No opinion,3,19,No opinion,1,18,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +No opinion,1,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,6,5,No opinion,No opinion,4,8,No opinion,7,No opinion,No opinion,2 +4,8,18,15,5,6,1,12,13,14,16,19,3,10,17,11,7,20,2,9 +6,12,8,18,4,13,1,5,17,2,16,9,3,7,19,14,11,20,10,15 +5,20,8,20,3,12,1,7,12,2,20,9,4,6,20,20,9,20,9,20 +10,11,20,14,19,2,18,16,4,1,7,6,17,13,5,3,8,12,9,15 +No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +8,14,6,17,13,4,20,16,18,1,19,12,5,2,15,3,7,9,11,10 +1,20,8,20,7,16,13,20,4,5,6,14,2,10,11,3,9,12,20,15 +19,16,17,19,8,3,4,6,5,3,2,11,1,19,19,7,10,15,12,9 +3,20,20,20,2,20,20,20,20,20,4,7,1,6,5,20,20,20,20,20 +9,11,13,15,2,1,7,20,12,3,6,14,8,4,19,5,16,18,10,17 +6,20,8,20,3,9,1,10,20,2,20,7,4,5,20,20,20,20,20,20 +1,20,6,20,5,4,20,20,2,3,20,20,20,7,9,20,20,20,8,20 +19,19,4,19,2,19,19,5,3,19,19,19,1,19,7,19,19,19,19,6 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +20,1,20,20,20,20,4,20,20,20,1,20,20,20,20,20,1,20,20,20 +9,No opinion,6,13,3,18,1,16,8,2,16,14,10,7,19,18,17,11,20,4 +No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,3,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,20 +4,20,3,20,5,20,20,20,20,20,20,6,20,20,2,20,20,20,20,1 +20,20,20,20,1,20,20,20,4,20,20,20,20,3,20,20,20,20,20,2 +6,8,1,No opinion,13,9,7,3,2,5,11,10,No opinion,14,4,No opinion,20,No opinion,No opinion,No opinion +10,7,12,18,17,8,15,4,2,5,6,3,9,19,1,16,11,15,15,20 +4,2,9,20,10,3,20,20,6,7,20,20,20,8,20,5,20,20,20,1 +5,19,6,20,9,1,No opinion,20,11,2,3,4,18,No opinion,20,12,10,7,20,8 +No opinion,No opinion,1,No opinion,No opinion,4,No opinion,No opinion,3,5,No opinion,No opinion,No opinion,2,6,7,No opinion,No opinion,No opinion,No opinion +5,20,5,20,3,20,4,20,2,20,20,20,1,6,20,20,20,20,20,20 +6,20,1,7,20,3,8,20,20,5,2,20,20,4,9,20,20,20,20,20 +12,11,1,14,2,10,20,3,4,7,9,13,6,8,15,19,16,18,17,5 +5,20,20,20,2,20,6,20,4,20,15,20,1,4,20,20,20,20,20,3 +8,15,10,19,7,6,1,2,3,12,17,5,4,9,18,20,14,16,11,13 +6,2,20,20,20,5,20,20,20,1,3,4,20,8,20,20,9,20,7,20 +5,8,6,9,2,18,4,20,15,16,20,7,1,12,11,17,10,19,13,3 +5,12,8,11,3,4,2,12,12,1,10,12,12,6,12,12,7,12,11,7 +2,9,12,20,5,20,4,11,8,6,20,20,3,7,10,20,20,20,20,1 +20,20,20,20,1,20,20,20,20,20,20,20,2,20,20,20,20,20,20,20 +5,20,6,20,3,20,2,20,20,20,8,20,1,7,20,20,20,20,20,4 +1,3,No opinion,No opinion,No opinion,1,3,No opinion,3,1,2,No opinion,No opinion,No opinion,2,No opinion,2,No opinion,No opinion,No opinion +1,20,15,11,5,4,13,7,8,6,16,2,3,9,10,12,18,14,17,17 +4,2,1,1,2,No opinion,2,1,2,1,1,No opinion,2,20,No opinion,No opinion,5,2,3,1 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +9,5,18,18,10,19,11,18,8,6,18,18,1,4,3,18,2,20,18,7 +5,9,6,9,2,8,1,6,8,3,9,7,4,4,9,9,7,9,7,9 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +19,19,5,19,1,6,19,19,3,19,19,19,2,20,19,19,19,19,19,4 +No opinion,No opinion,1,No opinion,No opinion,7,No opinion,No opinion,No opinion,2,6,No opinion,No opinion,No opinion,No opinion,4,No opinion,3,5,No opinion +6,14,4,11,5,16,2,1,8,3,17,20,18,19,15,13,10,12,9,7 +4,5,20,20,2,20,1,20,20,20,20,20,3,20,20,20,20,20,20,20 +10,20,20,20,20,1,20,20,20,2,20,20,20,20,20,20,20,20,20,10 +9,19,19,19,4,20,11,19,19,5,6,7,10,19,12,2,19,1,5,3 +3,No opinion,4,No opinion,3,No opinion,No opinion,2,1,2,5,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +1,No opinion,2,No opinion,1,3,1,1,2,3,3,2,1,2,2,No opinion,No opinion,No opinion,No opinion,1 +2,20,20,20,20,20,20,20,20,20,20,20,3,4,20,20,20,20,20,1 +20,17,3,20,1,20,5,17,14,4,20,17,2,20,20,18,19,20,19,17 +6,12,8,20,3,7,1,5,9,2,13,16,10,4,20,15,11,14,17,20 +20,20,20,20,20,20,10,20,20,20,20,20,20,1,20,20,20,20,20,10 +18,11,3,16,4,7,1,9,6,10,2,5,19,20,17,15,13,12,8,14 +3,9,7,15,11,20,8,1,19,13,4,14,12,6,10,16,18,2,17,5 +2,20,3,2,2,20,20,20,20,20,1,1,2,2,3,20,20,20,20,20 +8,9,3,No opinion,1,10,4,7,10,10,6,No opinion,2,14,No opinion,10,No opinion,No opinion,No opinion,5 +20,1,11,20,15,3,6,8,5,7,15,9,20,4,15,2,13,10,16,12 +3,20,6,20,4,9,2,20,20,5,20,8,20,20,20,10,20,20,20,7 +6,20,20,20,2,20,3,20,7,7,20,5,4,20,20,8,20,20,7,1 +20,20,20,6,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,5 +3,13,8,20,2,16,1,6,12,4,18,9,7,5,19,15,10,14,11,17 +3,20,6,20,1,20,20,20,5,20,20,20,2,4,20,20,20,20,20,20 +6,19,19,1,19,4,19,5,19,2,19,3,19,19,20,19,19,19,19,19 +2,3,6,No opinion,No opinion,8,No opinion,1,7,9,No opinion,No opinion,No opinion,No opinion,No opinion,5,4,No opinion,No opinion,20 +3,4,No opinion,No opinion,8,9,No opinion,No opinion,11,5,10,6,15,1,7,No opinion,2,12,No opinion,13 +20,20,20,20,20,2,20,1,2,2,20,20,20,3,20,20,3,20,20,2 +5,10,3,12,6,14,9,1,7,4,13,17,19,11,15,20,8,2,16,18 +5,11,8,20,3,14,1,7,13,2,18,10,4,6,19,16,9,15,12,17 +12,8,14,No opinion,4,10,No opinion,9,7,2,11,No opinion,No opinion,No opinion,No opinion,6,5,1,3,13 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +6,20,20,20,3,20,1,20,20,2,20,20,4,5,20,20,20,20,20,20 +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +6,20,8,20,2,20,1,5,12,3,19,20,3,6,20,18,20,20,20,17 +4,1,20,20,20,1,20,20,5,2,4,3,20,3,20,20,20,20,20,3 +3,4,No opinion,No opinion,1,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,3 +20,10,20,10,5,20,6,10,20,4,10,3,1,20,10,20,10,10,10,2 +10,20,1,20,1,2,10,1,15,15,4,4,1,20,10,20,15,15,20,15 +20,20,20,20,20,20,20,20,20,20,20,20,20,1,20,20,20,20,20,20 +2,5,19,7,3,9,1,6,10,11,5,5,5,12,20,10,17,4,8,9 +6,9,3,17,13,17,13,1,17,3,9,3,17,6,9,13,9,1,13,6 +2,No opinion,No opinion,No opinion,No opinion,No opinion,1,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +6,14,8,20,3,13,1,7,12,2,18,9,4,5,19,16,10,15,11,17 +8,2,4,10,6,18,20,3,9,16,17,5,14,7,12,13,1,11,15,19 +5,7,20,20,2,20,3,5,20,20,20,20,1,20,20,20,20,20,20,3 +No opinion,No opinion,20,No opinion,No opinion,No opinion,20,No opinion,20,No opinion,No opinion,No opinion,20,1,No opinion,No opinion,No opinion,No opinion,No opinion,20 +20,14,13,16,1,12,3,17,8,4,19,10,2,18,18,11,7,15,6,5 +6,20,4,5,11,7,8,9,3,15,10,1,2,16,12,13,19,17,14,18 +1,No opinion,No opinion,No opinion,No opinion,2,4,5,No opinion,No opinion,No opinion,3,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +4,No opinion,No opinion,No opinion,3,No opinion,1,No opinion,No opinion,2,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion,No opinion +19,17,19,6,20,19,20,1,19,19,16,17,20,3,17,2,17,18,17,16 +20,7,12,16,8,2,20,4,5,10,16,16,3,6,20,16,9,11,16,1 +3,4,5,20,20,20,2,20,20,3,20,20,20,1,20,20,20,3,2,4 +13,7,5,20,1,9,3,4,2,6,8,5,1,11,10,10,20,20,20,12 +7,20,20,1,20,5,4,8,20,20,6,7,2,10,9,20,20,20,20,3 diff --git a/events/elections/2017/README.md b/events/elections/2017/README.md new file mode 100644 index 00000000..0d17f68c --- /dev/null +++ b/events/elections/2017/README.md @@ -0,0 +1,77 @@ +# 2017 VOTERS GUIDE - KUBERNETES STEERING COMMITTEE ELECTION + +This election has been completed. + +[Results](RESULTS.md) + +# PURPOSE +The initial role of the steering committee is to instantiate the formal governance process for Kubernetes. In addition to defining the initial governance process, the [bootstrap committee](https://groups.google.com/forum/#!msg/kubernetes-dev/4e8WOnMvZC0/57GYmJKfDAAJ) strongly believes that it is important to provide a means for iterating the processes defined by the steering committee. We do not believe that we will get it right the first time, or possibly ever, and won’t even complete the governance development in a single shot. The role of the steering committee is to be a living, responsive body that can refactor and reform as necessary to adapt to a changing project and community. + +# VOTING +This election will shape the future of Kubernetes as a project and community. You will be voting on six (6) seats up for election, three with a two year term and three with an initial one year term. The motivation for these different terms is to set up an initial stagger so that the entire committee isn’t replaced every election cycle. After this first election, every elected community member will serve a two year term. + +The candidates you are voting on will be meeting regularly to strategically grow the project with contributors in mind. Most of the technical decisions, architecture planning, and the like come out of SIGs and other working groups. Some examples of responsibilities to consider as you are voting: +* Define, evolve, and defend the vision, values, mission, and scope of the project - to establish and maintain the soul of Kubernetes +* Charter and refine policy for defining new community groups (including Special Interest Groups, Working Groups, and Committees), and establish transparency and accountability policies for such groups. +* Define, evolve, and defend a Code of Conduct, which must include a neutral, unbiased process for resolving conflict + +Full scope of responsibilities, goals, and/or future election timelines, see [steering committee charter](https://github.com/kubernetes/steering/blob/master/charter.md). + +For more context, please see the [current issues](https://github.com/kubernetes/steering/blob/master/backlog.md) that need to be resolved or a previous governance [meeting video](https://www.youtube.com/watch?v=ltRKXLl0RaE&list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ&index=23) which lead to this whole process. + +## PROCESS +Elections will be held using time-limited [Condorcet](https://en.wikipedia.org/wiki/Condorcet_method) ranking on [CIVS](http://civs.cs.cornell.edu/) using the [Schulze method](https://en.wikipedia.org/wiki/Schulze_method). The top vote getters, modulo the corporate diversity requirement of no more than 1/3 of the committee from a single company, will be elected to the respective positions, with the top 3 filling the 2 year term seats, and the next 3 filling the 1 year term seats. + +You will be ranking your choices 1-20 with an option for no opinion. In the event of a tie, a coin will be flipped. + +The election will open for voting on September 19, 2017 at 09:00am PDT and end two weeks after on October 3, 2017 at 06:00pm PDT. You will receive an email to the address on file at the start of the election from Jorge Castro (jorge@heptio), Community Manager, please whitelist if necessary. Detailed voting instructions will be addressed in email and the CIVS polling page. + +## ELIGIBILITY +Members of Standing are defined by the union of: +* SIG leads +* Approvers and reviewers in any Kubernetes owned repositories +* Anyone with write access to a Kubernetes owned repository +* Active members of our community +If you believe you are a Member of Standing, please fill out [this form](https://docs.google.com/forms/d/e/1FAIpQLSeoeNSl9ufZ_jpp7OHgvtWm-GRFV6WUwTIqZ9W25eMd3xyyvg/viewform) before September 13, 2017. + +## DECISION +The newly elected body will be announced in the weekly Kubernetes Community Meeting on October 5, 2017 at 10:00am US Pacific Time. [Please join us](https://groups.google.com/forum/#!forum/kubernetes-community-video-chat). + +Following the meeting, the raw voting results and winners will be published on the [Kubernetes Blog](http://blog.kubernetes.io/). + +For more information, definitions, and/or detailed election process, see full [steering committee charter](https://github.com/kubernetes/steering/blob/master/charter.md). + +# NOMINEES +Don’t know someone on this list? We asked the nominees to provide a <300 word bio about their k8s experience that we'll link to their name in this table. + +Name | Organization/Company | GitHub +--- | --- | --- +[Aaron Crickenberger](aaroncrickenberger_bio.md) | Samsung SDS | [@spiffxp](https://github.com/spiffxp) +[Aaron Schlesinger](aaronschlesinger_bio.md) | Microsoft | [@arschles](https://github.com/arschles) +[Adnan Abdulhussein](adnanabdulhussein_bio.md) | Bitnami | [@prydonius](https://github.com/prydonius) +[Alex Pollitt](alexpollitt_bio.md) | Tigera | [@lxpollitt](https://github.com/lxpollitt) +[Caleb Miles](calebamiles_bio.md) | CoreOS | [@calebamiles](https://github.com/calebamiles) +[Derek Carr](derekcarr_bio.md) | Red Hat | [@derekwaynecarr](https://github.com/derekwaynecarr) +[Doug Davis](dougdavis_bio.md) | IBM | [@duglin](https://github.com/duglin) +[Ihor Dvoretskyi](idvoretskyi_bio.md) | CNCF | [@idvoretskyi](https://github.com/idvoretskyi) +[Ilya Dmitrichenko](errordeveloper_bio.md) | Weave | [@errordeveloper](https://github.com/errordeveloper) +[Jaice Singer DuMars](jaicesingerdumars_bio.md) | Microsoft | [@jdumars](https://github.com/jdumars) +[Justin Santa Barbara](vote_for_justinsb.md) | Independent | [@justinsb](https://github.com/justinsb) +[Kris Nova](kris-nova_bio.md) | Microsoft | [@kris-nova](https://github.com/kris-nova) +[Matt Farina](mattfarina_bio.md) | Samsung SDS | [@mattfarina](https://github.com/mattfarina) +[Michael Rubin](michaelrubin_bio.md) | Google | [@matchstick](https://github.com/matchstick) +[Michelle Noorali](michellenoorali_bio.md) | Microsoft | [@michelleN](https://github.com/michelleN) +[Phillip Wittrock](pwittrock_bio.md) | Google | [@pwittrock](https://github.com/pwittrock) +[Quinton Hoole](quintonhoole_bio.md) | Huawei | [@quinton-hoole](https://github.com/quinton-hoole) +[Rob Hirschfeld](rhirschfeld_bio.md) | RackN | [@zehicle](https://github.com/zehicle) +[Sebastien Goasguen](sebastiengoasguen_bio.md) | Bitnami | [@sebgoa](http://github.com/sebgoa) +[Timothy St. Clair](timothysc_bio.md) | Heptio | [@timothysc](https://github.com/timothysc) + + +Note:The bootstrap committee members have +recused themselves from any form of electioneering, including +campaigning, nominating, endorsing, or even asking people to run. + +Please direct any questions via email to
+[K8s Slack](http://slack.k8s.io/) + diff --git a/events/elections/2017/RESULTS.md b/events/elections/2017/RESULTS.md new file mode 100644 index 00000000..008ac2ff --- /dev/null +++ b/events/elections/2017/RESULTS.md @@ -0,0 +1,53 @@ +# Results of the 2017 Steering Committee Election + +Number of seats open: 3 (2 year term), 3 (1 year term) + +Number of eligible voters: 392 + +Number of votes cast: 309 + +Turnout: 78.8% + +[Raw ballot data](BALLOTS.csv) + +## Results + +The final ranking, using the "Schulze" Condorcet completion, is as follows: + +1. Derek Carr +2. Michelle Noorali +3. Phillip Wittrock +4. Michael Rubin +5. Timothy St. Clair +6. Quinton Hoole +7. Aaron Crickenberger +8. Caleb Miles +9. Jaice Singer DuMars +10. Kris Nova +11. Justin Santa Barbara +12. Alex Pollitt +13. Sebastien Goasguen +14. Ihor Dvoretskyi +15. Adnan Abdulhussein +16. Ilya Dmitrichenko +17. Matt Farina +18. Aaron Schlesinger +19. Rob Hirschfeld +20. Doug Davis + +According to the limits on company representation, Google would be +over-represented with this result, so Michael Rubin must be excluded. + +## Winners + +The winners of the open seats are as follows: + +Two year term: +1. Derek Carr +2. Michelle Noorali +3. Phillip Wittrock + +One year term: +1. Timothy St. Clair +2. Quinton Hoole +3. Aaron Crickenberger diff --git a/events/elections/2017/aaroncrickenberger_bio.md b/events/elections/2017/aaroncrickenberger_bio.md new file mode 100644 index 00000000..d3773272 --- /dev/null +++ b/events/elections/2017/aaroncrickenberger_bio.md @@ -0,0 +1,23 @@ +# Aaron Crickenberger + +I can be reached as [@spiffxp](https://github.com/spiffxp) on github, slack, gmail, linkedin, twitter, soundcloud, etc + +## What I've done + +I have been involved in open source projects since 2007, cloud related projects since 2009, and Kubernetes since 2015. + +I co-founded SIG Testing. I actively contribute in SIG Contributor Experience, Release, Scale. If you attend the weekly Kubernetes Community meetings, chances are you've seen me (or at least my beard.) + +I have participated in every Kubernetes release since v1.4. I drafted release notes for [v1.4](https://github.com/kubernetes/kubernetes/pull/33410) and [v1.5](https://github.com/kubernetes/features/pull/140). I am a member of of the [v1.8 release team](https://github.com/kubernetes/features/blob/master/release-1.8/release_team.md). + +I helped found [the kubernetes/community repo](https://github.com/kubernetes/community/pull/3). + +## What I'll do + +[The same thing we do every night Pinky...](https://www.youtube.com/watch?v=XJYmyYzuTa8) + +I will advocate for transparency and accountability in our decision making process. I will strive for simplicity and human-sized solutions to large-scale problems where possible. I will continue to push for community empowerment and ownership of key project responsibilities. Narf. + +## Where I work + +Samsung SDS, as part of the [Cloud Native Computing Team](https://samsung-cnct.github.io) diff --git a/events/elections/2017/aaronschlesinger_bio.md b/events/elections/2017/aaronschlesinger_bio.md new file mode 100644 index 00000000..84f043ec --- /dev/null +++ b/events/elections/2017/aaronschlesinger_bio.md @@ -0,0 +1,53 @@ +# Aaron Schlesinger + +- Github: [arschles](https://github.com/arschles) +- Twitter: [@arschles](https://twitter.com/arschles) + +# About + +I'm a Sr. Software Engineer, Microsoft Azure Containers Group. + +I'm a passionate engineer, teacher and leader with over 10 years software engineering and +architecture experience. + +I believe that Kubernetes will truly succeed when we improve the developer and +user experience. + +# Experience + +I've made contributions to [helm](https://github.com/kubernetes/helm), [helm charts](https://github.com/kubernetes/charts), [minikube](https://github.com/kubernetes/minikube), [service-catalog](https://github.com/kubernetes-incubator/service-catalog) and I am a co-lead of SIG-Service-Catalog. + +Outside of Kubernetes, I've spent over 10 years speaking at conferences, teaching Go & Scala, +building large systems, sitting on standards bodies, and contributing to other open source +projects. + +# Promises + +Here are my promises to the community should I be elected to the committee. + +Above all, I want Kubernetes to be a nice place to work. That means: + +- Engineers can build or improve things easily +- Engineers have clear expectations how & (generally) when they will get feedback on their work +- Engineers get constructive feedback on their work +- Everyone is treated with respect, and can resolve interpersonal problems amicably + +Holistically, most of these points are true most of the time, but Kubernetes is growing so +fast and is so diverse that all of them are not always guaranteed right now. + +I realize no community can achieve everything all the time, but I believe we can do better +together. + +I want to improve the following immediately: + +- Improve user _and_ developer documentation +- Create clearer guidelines on how reviews should happen +- Clarify how to rise as a contributor + +Additionally, I'll contribute best to the committee as a representative of end users +and developers. + +I will keep the same promises in the steering committee as I do in SIG-Service-Catalog: + +- **I will always solicit user and developer experiences before making decisions** +- **I will always tackle user and developer problems before anything else** diff --git a/events/elections/2017/adnanabdulhussein_bio.md b/events/elections/2017/adnanabdulhussein_bio.md new file mode 100644 index 00000000..81371e5e --- /dev/null +++ b/events/elections/2017/adnanabdulhussein_bio.md @@ -0,0 +1,46 @@ +# Adnan Abdulhussein + +- GitHub/Slack/Twitter: @prydonius +- Email: adnan@bitnami.com + +## Background + +I joined the Kubernetes community in 2016, and have contributed in a number of +capacities since: + +- Core contributor of Helm +- Co-leading the Kubernetes Charts project +- Kicked off the Helm incubation process and community docs +- Co-leading SIG Apps +- Regularly speaking and advocating for Kubernetes + +Prior to my involvement in Kubernetes, I have been an active maintainer of +Bitnami's open source container images. My work at Bitnami is heavily focused on +making containers and Kubernetes both accessible and easy to use. + +I am honoured to be amongst the amazing group of people nominated for the +Steering Committee. If elected, my goal will be to help Kubernetes grow into a +rich and diverse community. + +## Where I see myself contributing + +As someone who isn't completely focused on Kubernetes core, I think an important +part of the project is the ecosystem around it. I am deeply interested in being +part of discussions, as part of the Steering Committee, to define the vision of +the project, and to decide what relevant sub-projects should be part of +Kubernetes to continue building a strong ecosystem and brand. This also means +making sure sub-projects have the resources they need (i.e. CI, documentation +websites) to succeed and promote their roles in the overall project. + +The diversity and inclusivity is one of the things that I value the most about +the Kubernetes community. I think it's important that we uphold these values +when defining and practicing a Code of Coduct and refining the contributor +experience. + +Another area of the Steering Commitee I'm interested in is furthering the +transparency and accountability for SIGs. I believe improving the communication +and enabling more knowledge sharing will empower both community and consumers. + +## Where I work + +Bitnami diff --git a/events/elections/2017/alexpollitt_bio.md b/events/elections/2017/alexpollitt_bio.md new file mode 100644 index 00000000..2dbd3f37 --- /dev/null +++ b/events/elections/2017/alexpollitt_bio.md @@ -0,0 +1,27 @@ +# Alex Pollitt + +I am excited to have been nominated for the steering committee. I recognize that doing +the role justice will be a demanding and time consuming commitment, but I would like +to do my part to help maintain and foster the growth of this amazing community of +contributors and users. + +For those of you who don’t know me, I am one of the founders of Tigera, the company behind +Calico, and active contributors to flannel, CNI, Kubernetes, and Istio. I’ve been working +with the Kubernetes community since 2014 and have great respect for everyone I’ve had the +chance to get to know along the way. + +Since the early days of the project, when friends used to ask, “which container orchestrator +would you bet on?”, my answer was always Kubernetes – not because of the great design +principles, but because of how the founding team and those already contributing welcomed +others to take part and collaborate with an equal voice to move the project forward. For me, +“Kubernetes” means the people and how they work together, as much as technology. + +One example I experienced was the k8s-sig-net efforts to agree a network policy API. In +other communities, this might have descended into vendors trying to get one up on each +other. Instead there was true collaboration, focusing on technical merit and meeting the needs +of future users. It was awesome to play a part in that process and even though it was just one +small corner of Kubernetes it’s a great illustration of why I love working in this community. + +If elected, I promise to do my utmost to foster and facilitate this kind of diverse, vendor +neutral, merit based collaboration, empower and support contributors to shape the project, +and maintain the spirit of this awesome community as it grows. diff --git a/events/elections/2017/calebamiles_bio.md b/events/elections/2017/calebamiles_bio.md new file mode 100644 index 00000000..452035a8 --- /dev/null +++ b/events/elections/2017/calebamiles_bio.md @@ -0,0 +1,52 @@ +# caleb miles + +## Contact Information + +- GitHub/Slack: @calebamiles +- Email: caleb.miles@coreos.com + +### Problem solving style + +I am a huge fan of ideas which simplify and unify, possibly due to my +undergraduate study of physics and mathematics. I believe that collaboration is +incredibly important and that continuous feedback on incremental solutions are +likely to produce the best outcome. I therefore try spend a lot of time talking +with people about the problems that are important to them before stepping back +to try to introduce a minimal solution based on their concerns. + +### Problems that are important to me + +I believe that addressing the dual challenge of communicating what everyone is +working on to other developers, and then explaining that work to users is one +of the most pressing issues for Kubernetes today. + +I also believe that we need to invest in the contributor experience particularly +by better supporting new contributors with mentorship programs, especially for +the self taught, new graduates, and underrepresented communities. If we are +going to be a successful and sustainable project we need to ensure that we +maintain a healthy pipeline of new contributors while at the same time reducing +the workload for more established contributors. + +Scaling contributions is another serious challenge for the project and I am very +interested in working on helping to support the effort to rethink the Kubernetes +release process. + +### Roles held + +I joined the community in 2016 since then I have made shallow contributions to + +- SIG Contributor Experience +- SIG Release +- SIG PM +- SIG Testing + +as well as serving in a minor capacity in the 1.5, 1.6, 1.7, and 1.8 releases. I +currently help to facilitate + +- SIG PM, co lead and co founder +- SIG Release, co lead and co founder + +### Where I work + +CoreOS + diff --git a/events/elections/2017/derekcarr_bio.md b/events/elections/2017/derekcarr_bio.md new file mode 100644 index 00000000..4f0f757a --- /dev/null +++ b/events/elections/2017/derekcarr_bio.md @@ -0,0 +1,43 @@ +# Derek Carr + +- GitHub: @derekwaynecarr +- Employer: Red Hat + +## Roles Held + +- Co-founder, lead: sig-node, wg-resource-management +- Participate: api-machinery, autoscaling, federation, scheduling, + service-catalog + +## About me + +I joined in 2014 as an early external contributor. After the first developer +summit, I realized I had a lot to learn from the experience of others. My first +PR enabled people to contribute to the project by running Kubernetes in a VM. +Mentors in the community helped multiply the quality of my contributions. With +their help, I designed and implemented namespaces, quota, limits, and much of +the supporting internal machinery like admission control, indexers, and clients +prior to the 1.0 release. + +As the project grew, SIGs developed to support specialized collaboration. I +co-lead SIG node and advocate for expanded workload support and improvements to +node reliability. To improve cross-SIG collaboration, I co-founded the Resource +Management Working Group to define a multi-release roadmap across SIGs (node, +scheduling, storage, etc). The cross-SIG working group concept has been adopted +across the community. I participate in multiple incubator projects with code +and coaching on technology and process. As every maintainer acknowledges, it is +impossible to know everything about Kubernetes. I prioritize mentoring others to +help them grow their scope and sustain the project. + +My experience reflects both a breadth and depth of commitment across Kubernetes +that would benefit the committee. I have a pragmatic approach to problem +solving that builds from the expertise of others and adopts minimal solutions +that have the best potential outcome. I iterate and improve. As a member of +the community, I hope the steering committee adheres to the same general +approach. + +## Where I see myself contributing + +- Responsibly grow contributor pool across all disciplines +- Clarify scope, structure, and responsibilities of SIGs and roles within +- Enhance Code of Conduct to nurture an inclusive, diverse, and open community \ No newline at end of file diff --git a/events/elections/2017/dougdavis_bio.md b/events/elections/2017/dougdavis_bio.md new file mode 100644 index 00000000..4a80fd85 --- /dev/null +++ b/events/elections/2017/dougdavis_bio.md @@ -0,0 +1,40 @@ +# Doug Davis + +- Github: [@duglin](https://github.com/duglin) +- Works for: IBM + +## Background + +I've been working on open source projects, and standards, for about 17 years, +starting with being a co-initiator of the Apache Axis project; working on +WS-* related projects and specifications, OpenStack, CloudFoundry, Docker +and now Kubernetes, including as a co-lead of the Service-Catalog Incubator. +I also founded the Web Services Testing Forum, a consortium of Web Service +providers and consumers designed for interop testing of SOAP/WS-* +specifications, as well as the [soaphub](http://soaphub.org) on-line +collaboration chat tool used by several communities. + +Throughout this time the importance of an open, fair and streamlined +collaboration process has really been a center piece of my activities and +goals for these projects. + +## Steering Committee + +The stated scope of the Steering Committee focuses on helping the +Kubernetes community define and optimize many of the (sometimes less than +glamorous, but necessary) processes and infrastructure that's critical +to keeping a community like Kubernetes healthy and successful. + +Kubernetes, as one of the fastest growing OSS projects, needs to navigate +and manage the complexities associated with this explosive growth very +carefully. The importance of balancing the need for continued enhancements, +managing stability of the code base, all while ensuring the community of +developers and users feel their contributions (from code, issues and feedback) +are welcome, respected and addressed in a timely fashion can not +be understated. This will require people who can consider the challenges +from multiple perspective, not just from a developer's. + +I believe that my background in the open communities I've been involved with +have given me a good perspective on what works, what doesn't and which might +be best for an organization like Kubernetes. + diff --git a/events/elections/2017/errordeveloper_bio.md b/events/elections/2017/errordeveloper_bio.md new file mode 100644 index 00000000..a667a2b4 --- /dev/null +++ b/events/elections/2017/errordeveloper_bio.md @@ -0,0 +1,33 @@ +# [Ilya Dmitrchenko](https://github.com/errordeveloper) + +## Manifesto + +Ilya has been contributing to Kubernetes since 2014. The focus of his contributions has been on solving +general cluster provisioning and bootstrap problems and making networking easier. For example in 2016, +he did the groundwork on the initial version of `kubeadm`. + +Ilya is a DX engineer at Weaveworks and is based in London. From there he travels (mostly in Europe) to +educate the wider community about the benefits of containers and orchestration with Kubernetes. Ilya +would be delighted to represent the European users as a member of the steering committee. + +Most recently, he started participating in organised community activities whose aim is to solve the +problems and the needs of end users who have Kubernetes in production or who are looking to put it in +production. To that end, he is a member of the London Production User Council, and together with other +contributors launched Kubernetes Office Hours. + +To learn more about Ilya's background and why he deeply cares about the community, please take a look at +his [personal blog](https://medium.com/@errordeveloper/a-little-more-about-me-b0b6238ba7f8). + + +## Key Priorities + + - Customer success with open-source Kubernetes + - Ease of use, in majority of general cases + - Growth of the community, and fairness + - Social and technical diversity + +## More Info + + - [Personal projects](https://github.com/errordeveloper) + - [Tweets](https://github.com/errordeveloper) + - [Personal blog](https://medium.com/@errordeveloper/a-little-more-about-me-b0b6238ba7f8) diff --git a/events/elections/2017/idvoretskyi_bio.md b/events/elections/2017/idvoretskyi_bio.md new file mode 100644 index 00000000..c4e8c002 --- /dev/null +++ b/events/elections/2017/idvoretskyi_bio.md @@ -0,0 +1,24 @@ +# Ihor Dvoretskyi + +Twitter: https://twitter.com/idvoretskyi + +GitHub: https://github.com/idvoretskyi + +Anywhere else: @idvoretskyi + +## About me + +I'm a [Developer Advocate for Cloud Native Computing Foundation](https://www.cncf.io/blog/2017/09/18/meet-cncfs-newest-developer-advocate/), open source lover, passionate about the technologies and open source adoption; with the deep technical background, together with program and product management experience in the open source world. In a previous life, I’ve been a System Administrator and DevOps Engineer, passionate about the Cloud technologies. Later, I’ve joined Mirantis, one of the largest players in the OpenStack world, where I’ve started my collaboration with OpenStack community. + +I've enjoyed Kubernetes since the early days. I've started researching it in mid-2014 when it was publicly announced; I've been using for my projects it in mid-2015 when it had reached its 1.0 milestone; and I've started contributing (as an individual contributor) to Kubernetes in late-2015, when I felt that my knowledge and experience might be useful for the project. + +As a Kubernetes Community member, I'm mostly focused on Product- and Project-management areas, with the primary interest in the features and roadmap scope. +For Kubernetes 1.3, 1.4 and 1.5 I've been unofficially involved in the release process with the features tracking and management. +Since Kubernetes 1.6 release cycle (and continued these efforts during 1.7 and 1.8), I've joined the release teams as the release manager, responsible for the features. +Finally, I've been one of the co-founders of [SIG-PM](https://github.com/kubernetes/community/tree/master/sig-product-management), responsible for managing Kubernetes-as-a-project and Kubernetes-as-a-product. + +Besides that, as an individual with OpenStack community background, I'm co-leading [SIG-OpenStack](https://github.com/kubernetes/community/blob/master/sig-openstack/README.md), building the relationships between two major open source communities. + +## What's next? + +As a vendor-neutral Kubernetes contributor, I'm going to continue my work on enhancing Kubernetes as an open source project, technology stack, and one of the largest open source communities in the world. diff --git a/events/elections/2017/jaicesingerdumars_bio.md b/events/elections/2017/jaicesingerdumars_bio.md new file mode 100644 index 00000000..90ba0ee3 --- /dev/null +++ b/events/elections/2017/jaicesingerdumars_bio.md @@ -0,0 +1,20 @@ +# Jaice Singer DuMars + +## Contact Information + +- GitHub: [@jdumars](https://github.com/jdumars) +- Twitter: [@jaydumars](https://twitter.com/jaydumars) +- LinkedIn: [Jaice Singer DuMars](https://www.linkedin.com/in/jasondumars/) +- Works for: Microsoft + +## Why me? + +The steering committee represents a unique convergence of my passion for servant leadership, organizational dynamics, inclusion, advocacy, and process optimization. It's always my highest purpose to be a voice and advocate for those I serve. And, if elected, I will faithfully serve the ever-changing, sometimes divergent, and always important needs of the Kubernetes community. + +## Servant leadership + +Since my first moments in the community, I have sought out every opportunity I can to make things better. I wrote an article about this called [What Kubernetes means to me](http://bit.ly/k8s2me) that will shed some light on my journey to this point. My contributions to the community currently include leading the 1.8 release team, co-leading SIG Azure, SIG Architecture, and SIG Cluster Ops (although Rob Hirschfeld has been covering for me while I work on the release). I have facilitated every release retrospective since 1.3, and have improved my typing skills by note taking at countless SIG meetings. I also work behind the scenes on Community things with Sarah and Jorge. + +## Career + +I've been in love with systems, networks, and the human elements of interconnectivity since I was a SysOp on a BBS as a teenager. My first hack was in grade school, making the Oregon Trail game say naughty things. In the time since, I have been a systems and network engineer, and held several engineering management directorships at companies large and small. At Microsoft, all I do is Kubernetes, so I definitely have the organizational support to carry out my duties on the committee. diff --git a/events/elections/2017/kris-nova_bio.md b/events/elections/2017/kris-nova_bio.md new file mode 100644 index 00000000..371379d4 --- /dev/null +++ b/events/elections/2017/kris-nova_bio.md @@ -0,0 +1,36 @@ +# Kris Nova + +## What is important to me + +Mental, philosophical, and design diversity. Period. + +I truly believe that the best teams and projects are those that embrace unique and sometimes conflicting ways of thinking. + +Having a leadership board of people who all think the same way, and all are moving in the right direction is stale and stagnant. + + - I want to help foster diversity in Kubernetes in both our design process, but also our goals and philosophies. + - I want to encourage my peers to put themselves into difficult, or testing situations in order to help grow and mature. + - I want to let others know that it's okay to try something and fail as we all learn as a scientific community. + + +## Work in the community + + - I spend as much of my free time as humanly possible contributing to Kubernetes. + - I take impromptu video calls with total strangers. + - I helped run *sig-aws* even though it conflicted with my dayjob. + - I created [kubicorn](https://github.com/kris-nova/kubicorn) in my free time and it has been reviewed as one of the best open source projects to contribute to in the space. + +## Reasons to pick me + +## I think differently. + +I question the world around me, and have been in a ton of different roles in engineering space. Including time in both genders. + +## I believe that software comes first. + +I love kubernetes regardless of my employer, and will always contribute because I believe in it. +I believe the way we continue to keep the project great is to focus on community, as well as writing kick ass software with a great user interface. + +## tldr + +I embrace being different and want to clean up our code and improve user experience. \ No newline at end of file diff --git a/events/elections/2017/mattfarina_bio.md b/events/elections/2017/mattfarina_bio.md new file mode 100644 index 00000000..2f4e6db9 --- /dev/null +++ b/events/elections/2017/mattfarina_bio.md @@ -0,0 +1,23 @@ +# [Matt Farina](https://www.mattfarina.com) +Technical leader, coder, author, presenter + +## Governance and Organization + +The steering committee is [chartered](https://github.com/kubernetes/steering/blob/master/charter.md) with figuring out the governance and organization of the Kubernetes community. Matt has years of experience in both non-profit and open source organizations. He has served on the board for two non-profits along with being involved in open source projects with mature governance models (e.g., Drupal and OpenStack). + +Matt believes that governance should enable people to easily navigate an organization and be empowered to be part of the community. That groups within an organization, such as special interest groups (SIG) and working groups, should have clearly communicated scope. This helps everyone understand how the organization is laid out while helping to highlight gaps. + +He also believes in diversity. This includes diversity of ideas and uses for Kubernetes. Diversity brings out ideas that can often be missing in an echo chamber of similar people with similar uses cases. Diversity leads to a stronger Kubernetes that's more capable of meeting real world needs. + +Matt wants to see Kubernetes as a professional community with an enjoyable experience for both contributors and consumers. + +## Technical Background + +Matt has been a contributor of open source for 15 years and a consumer of open source for over 20 years. In that time he has contributed to projects such as [Glide](https://glide.sh) (package manager), [Drupal](https://drupal.org), [OpenStack](https://www.openstack.org), and many others. While working in and out of open source Matt has had a focus on both software development and _user experience_. + +He has also authored technical books, hosted podcasts, and presented at numerous conferences. This has taught him how to clearly communicate with a wide variety of people. + +## Quick Details + +* Co-founded and co-leads SIG Apps +* Works for [Samsung SDS](https://samsung-cnct.github.io) diff --git a/events/elections/2017/michaelrubin_bio.md b/events/elections/2017/michaelrubin_bio.md new file mode 100644 index 00000000..09a4c5f7 --- /dev/null +++ b/events/elections/2017/michaelrubin_bio.md @@ -0,0 +1,36 @@ +# Michael Rubin Bio + +GitHub: @matchstick + +## About Me + +I have been a software engineer, technical manager, and leader for +~20 years. I am passionate about helping projects and people thrive. +Today I lead a number of Kubernetes teams at Google, including Storage, +Networking, Multi-cluster, Node, and more. + +I love coding and technology, but even more than that I love mentoring +others and helping them to have impact and grow professionally. This is +why I choose to support teams and projects as a technical manager. + +My leadership style is to bring sharp focus to technical efforts, and +to help others become successful leaders, themselves. I find that many +technology problems are not purely technical, and one of my biggest +strengths is my ability communicate, connect with people, and get to +the root of a problem. People are not machines, and they need different +skills than just pure engineering. + +During my 1.5 years with Kubernetes, I have worked directly and +indirectly with several SIGs - Storage, Multi-cluster, Networking, +Scheduling, and Node. I think I have brought clarity and structure to +the efforts, helped organize priorities and roadmaps, and helped the +teams and individuals grow. I have built lasting relationships with +the people of Kubernete, and not just the code. + +As a member of the Steering Committee, I would focus on: + + * Cross SIG efforts and how to co-ordinate them + * Getting more things out of core, but keeping them part of Kubernetes + * Maintain the cool, open and inviting environment we have today + * Delegate and empower others by adding structure (not process) + diff --git a/events/elections/2017/michellenoorali_bio.md b/events/elections/2017/michellenoorali_bio.md new file mode 100644 index 00000000..6d9faa0e --- /dev/null +++ b/events/elections/2017/michellenoorali_bio.md @@ -0,0 +1,35 @@ +# Michelle Noorali + +GitHub: [@michelleN](https://github.com/michelleN) + +Twitter: [@michellenoorali](https://twitter.com/michellenoorali) + +LinkedIn: [Michelle Noorali](https://www.linkedin.com/in/michelle-noorali-a588b516) + +## History & Roles Held + +- Working with Kubernetes and have been part of the community since mid-2015 +- Co-founded and Co-lead Kubernetes SIG Apps for focusing on defining and managing applications in Kubernetes +- Core Maintainer of the Kubernetes Helm project +- Co-chair CloudNativeCon & KubeCon 2017 + +## Why I'm here + +The Kubernetes community has been a special place for me, and I'm glad to be part of it. I have found it exciting to work collaboratively with folks from different organizations, backgrounds, parts of the world, and industries on problems that matter to all of us sometimes even for different reasons, so I enjoy and place great value on communicating effectively and balancing different perspectives for technical solutions. + +Because Kubernetes is such an empowering piece of technology, I am obsessed with helping make sure that it is usable across audiences. This is where the bulk of my work with [SIG-Apps](https://github.com/kubernetes/community/tree/master/sig-apps) comes in. We've been working for almost a year and a half on making the process of defining and managing applications in Kubernetes easier and the best experience possible. Throughout this process, we've repeatedly re-defined how our SIG functions and how it can best serve the community. We focused on creating a tight feedback loop with the folks who consume apps features in Kubernetes and those who help create and maintain those features. We share solutions to common sets of problems, and we ensure that the solutions presented are set up for success by helping our presenters set the right context for the audience. We even focus on the flow of our meetings to make sure that people are able to follow along making the SIG content digestable, empowering newcomers in the space, and helping funnel more opinions into feedback loops. I believe SIGs are a fundamental part of the Kubernetes community and one of the big reasons the community is so successful. I am particularly passionate about supporting SIGs and making them even stronger than they are today using my experience with SIG Apps. + +Lastly, it has been rewarding for me to help people begin their journey in the Kubernetes community by guiding them to the right place to get what they need. I've enjoyed being part of the growth of this community and want to ensure that it remains an approachable one as well as an inclusive place to work. + +## Key priorities + +- Making sure people are heard +- Making sure opinions are respected +- Helping ensure the right context is set when discussing concerns and ideas +- Helping people be successful in whatever area they are in +- Empowering newcomers +- Empowering SIGs and SIG leads + +## Where I work + +Microsoft Azure, previously Engine Yard/Deis diff --git a/events/elections/2017/pwittrock_bio.md b/events/elections/2017/pwittrock_bio.md new file mode 100644 index 00000000..a6defb9b --- /dev/null +++ b/events/elections/2017/pwittrock_bio.md @@ -0,0 +1,55 @@ +# Phillip Wittrock Bio + +GitHub: @pwittrock + +## Problem solving style + +- Incremental approach to problem solving +- Try new things - build and iterate on minimalist solutions + +## What I find important + +I care deeply about helping people feel positive about what they are doing and empowered to do more. +Within the Kubernetes community, I would like to focus on helping ensure contributors': + +- time and contributions are impactful +- time and contributions are recognized and appreciated +- opinions are listened to and valued + +## Where I see myself contributing + +I believe it is important for the processes for contribution and maintenance of the project +to be well communicated and understood within the community. +I would like to be involved in areas owned by the SC such as - helping to develop a +SIG charter template, simplifying the contributor ladder, documenting resources the community has, +and helping to find a home for unowned areas of the project. + +## Roles held + +Since joining the community in 2015, I have made contributions in various roles +(developer, SIG-lead, docs, release manager) across the project. Working +in these capacities has given me insight into the challenges faced throughout the project. + +Areas of the project I have contributed to include: node, kubectl, service catalog, docs and release. + +### Current SIG lead positions I hold + +- Co-founded SIG-cli +- Co-founded SIG-release + +### Emeritus SIG lead positions I have held (brief tenure) + +- Bootstrap SIG-contribX +- Bootstrap SIG-docs + +### Relevant non-technical contributions + +- (release) Changed management role from an individual to a team with defined roles +- (release) Proposals for streamlining and automating various processes +- Published community membership ladder developed from draft (draft by Brian Grant) +- 1.4 release czar +- Participated in 1.5, 1.6 and 1.7 releases + +## Where I work + +Google \ No newline at end of file diff --git a/events/elections/2017/quintonhoole_bio.md b/events/elections/2017/quintonhoole_bio.md new file mode 100644 index 00000000..d72d6aa0 --- /dev/null +++ b/events/elections/2017/quintonhoole_bio.md @@ -0,0 +1,66 @@ +# Quinton Hoole + +- Github: [quinton-hoole](https://github.com/quinton-hoole) + +# About Me + +Currently I'm Technical Vice President of Cloud Computing At Huawei +Technologies (185,000 employees globally, US$75BN annual revenue +(2016), 32% annual revenue growth). + +I was the founding engineer of Amazon EC2 (2005-2010). + +I was the lead engineer at Nimbula.com (2010-2012), a Cloud IaaS +startup which was acquired by Oracle in 2013. + +I was at Google from 2012-2016, first as Technical Lead and Manager of +Ads Serving SRE, and then Engineering Lead on the Kubernetes team +(2014-2016). + +Prior to 2005, I co-founded two startups (one in the online travel +industry, the other in financial services), on both of which I served +as lead techie until they were acquired by public companies. I have +also worked as a consultant, contractor and technical leader in the +telco, financial and retail industries. + +I have an M.Sc in Computer Science. + +# Highlights of What I've done on Kubernetes thus far + +Initially I led the effort to get our CI Testing stuff initiated and +[working effectively](https://github.com/kubernetes/community/blob/master/contributors/devel/writing-good-e2e-tests.md), which was critical to being able to launch v1.0 successfully, +way back in July 2015. Around that time I handed it over to the now-famous SIG-Testing. + +After that I initiated and led the [Cluster +Federation](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/federation/federation.md) +effort, which has spilled over and touched many aspects of Kubernetes +in one way or another (API, Networking, Security, Scalability, Resiliency, +Testing etc). + +Along the way I also helped the [Scalability folks to set some key +objectives](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md). + +# How I Hope to Serve You on the Steering Committee + +I am a strong believer that Cloud Computing will change the world +(even more so than it already has), and that Kubernetes is the next +big step in this exciting journey. + +To realize this potential, I believe that we need to create both a +thriving, collaborative community, and freaking awesome software that +people love to use, everywhere. We're doing pretty well in both of +these areas, but there's still a lot of room for improvement. So I'd +like to offer my broad and deep experience, time and passion to help +us to get there. Hopefully my track record will help to convince you +that I'm fairly good at identifying good things for us to do, figuring +out how best to do them, and getting them done. Along the way I have +accumulated more than a few scuffs and bruises, as well as a few +victories, so hopefully I can help us to avoid some of the former. + +More specifically, I'd like to help us to (amongst others): + +- ensure that Kubernetes remains a fun place to develop stuff that + people love to use. +- create effective incentives to motivate constructive, productive + and sustainable progress. +- protect what we have built (and will build) from bad things happening. diff --git a/events/elections/2017/rhirschfeld_bio.md b/events/elections/2017/rhirschfeld_bio.md new file mode 100644 index 00000000..c3994be7 --- /dev/null +++ b/events/elections/2017/rhirschfeld_bio.md @@ -0,0 +1,27 @@ +# Rob Hirschfeld Bio + +* GitHub: [@zehicle](https://github.com/zehicle) +* Twitter: [@zehicle](https://twitter.com/zehicle) +* Blog: [RobHirschfeld.com](http://robhirschfeld.com) +* I work at [RackN.com](https://RackN.com) and live in Austin, Texas. + +## Governance Perspective: it's about people, not tech + +Open source infrastructure automation is a critical foundation for the Internet and, thus, advancing society as a whole. In a very practical way, protecting open software is essential to building a better world. I am seeking a seat on the Kubernetes Steering Committee because I bring special perspectives to governing the project. + +## Leadership: Technical, Open Source and Business + +I’ve demonstrated practical and relevant experience to building open governance at this stage in our development. + +* **Open source project founder ([Digital Rebar](http://rebar.digital), Crowbar)**: I know the challenges of sustaining contribution +* **Operator**: I’ve run infrastructure and founded the SIG Cluster Ops group to give a voice for operators. I focus professionally on helping promote SRE and DevOps practices. +* **Founding OpenStack board member (4 terms)**: I’ve built open governance processes and done the hard work to build conformance and core definition (#DefCore) patterns. +* **Start-up founder (RackN.com)**: I’ve done every role and am willing to get my hands dirty. I understand the needs for small companies trying to support large projects. +* **Dell Executive**: I’ve been part of large organizations and know how to explain things in corporate speak to protect project interests. +* **Technologist**: I still write code and build applications as needed so I understand the very specific concerns of delivering working platforms. + +## TL;DR: Collaborative and Principled + +Most importantly, I’m collaborative by nature. I know how to stand my ground and fight without being a jerk or excluding people. I can be one of the advocates that the Kubernetes community needs as we build formal governance. + +_Governance means being able to say no and keep consensus._ diff --git a/events/elections/2017/sebastiengoasguen_bio.md b/events/elections/2017/sebastiengoasguen_bio.md new file mode 100644 index 00000000..065bf8eb --- /dev/null +++ b/events/elections/2017/sebastiengoasguen_bio.md @@ -0,0 +1,30 @@ +# Sebastien Goasguen + +## Contact + +* GitHub: [@sebgoa](https://github.com/sebgoa) +* Twitter: [@sebgoa](https://twitter/sebgoa) +* Linkedin [Profile](https://www.linkedin.com/in/sebastien-goasguen-382b7b21/) +* Employer: Bitnami + +## Vision + +Being a member of the steering committee is not a technical role, it is a temporary position to help the community grow and ensure that the project (at large) succeeds in the long term. + +The steering committee already has a long backlog of things to do and I submitted a [PR](https://github.com/kubernetes/steering/pull/2) some time ago to show my take on it. Within that backlog, I see three main areas that need a lot of clarity. + +* Membership. Our membership and roles have grown organically, driven by our velocity and the limitations of GitHub. I would like to see us step back a bit and clearly define our membership ladder and ways by which contributors navigate it. This would provide clear criteria for example to define who is a "person of standing" and how you become one. + +* Decision making. We have a lot of slack channels, hangouts and mailing lists. However we do not know where decisions are made, when and how. We need to bring clarity to our decision making processes so that everyone feels that they own the decision. It is also a major issue of inclusiveness which can lead to fragmentation of the community. + +* Incubator. We have an incubator but I believe we need to revise its "charter" now that several projects have graduated. We need more mentoring and support of the incubating projects. Moreover, the graduation criteria, need to encompass a more visible decision process (currently only 2 people decide if a project graduates). + +My experience at the Apache Software Foundation (member and part of several project management committee) can be extremely helpful. Not to apply the exact same principles and processes but to find a balance and bring a perspective from an established open source foundation that is totally vendor neutral, based on meritocracy, has an incubator and clear decision making processes. + +## Diversity + +My name is in a French dialect (Breton), it literally means "white man". However Kubernetes is a worldwide community and I believe it needs representation from different nationalities, cultural background and from people who do not necessarily speak English as their mother tongue. I believe I can be that little voice which brings a bit of balance in an otherwise heavily US dominated steering committee. + +## Kubernetes Background + +I have been involved with Kubernetes since [Sept 2014](https://github.com/kubernetes/kubernetes/pull/1411) and focused on tools in the ecosystem. My startup [Skippbox](https://github.com/skippbox) created several tools including: kompose, kmachine, Cabin and [kubeless](http://kubeless.io). We joined Bitnami in March 2017 where I lead all our Kubernetes efforts. I helped very early on with Helm and Charts. I try to help with the Python client and mentored a GSoC student this summer. I also do a fair share of advocacy and training and I am the co-author of the upcoming Kubernetes cookbook. diff --git a/events/elections/2017/timothysc_bio.md b/events/elections/2017/timothysc_bio.md new file mode 100644 index 00000000..9daeee9f --- /dev/null +++ b/events/elections/2017/timothysc_bio.md @@ -0,0 +1,26 @@ +# Timothy St. Clair + +## Contact Information + +- GitHub/Slack: [@timothysc](https://github.com/timothysc) +- Email: tstclair@heptio.com +- Twitter: [@timothysc](https://twitter.com/timothysc) + +## Background + +I've been involved in the Kubernetes project since 2014, and prior to that I was an active member in the Mesos community, with over 10+ years of experience working on open source projects across a plethora of communities. During my tenure, I've been lucky enough to meet a number of great folks working on various SIGs: + +- SIG Scheduling & Testing (Lead) +- SIG Scale, Cluster Life-cycle, API Machinery, Node (Contributor) + +## Why I want to be on the Steering Committee (Optimize, Simplify, and Empower) + +Time is our most precious commodity, and few things can be more frustrating than wanting to contribute only to watch patches bit-rot, have legitimate issues sit unaddressed, or type `/retest` for the 10th time. My primary goal in running for a position on the steering committee is optimize processes such that no one feels like their time is wasted working on this project. As of today, the process that a contributor needs to follow is byzantine, and can be daunting for folks who are new to the community. (Optimize) + +However, it doesn't stop there. In order for the community to thrive, we need to continually reevaluate our processes to ensure what we are doing makes sense, and ensure those processes are simple and concise. (Simplify) + +Lastly, I want to help promote and empower folks in the community to take on some of the roles that have traditionally been filled by google. Once core aspects of the test and release process can be done by non-googlers I think we've reached a point where we have empowered the broader community. (Empower) + +## Where I work + +Heptio diff --git a/events/elections/2017/vote_for_justinsb.md b/events/elections/2017/vote_for_justinsb.md new file mode 100644 index 00000000..bae8ece2 --- /dev/null +++ b/events/elections/2017/vote_for_justinsb.md @@ -0,0 +1,43 @@ +## Vote for justinsb! + +You can see my full "manifesto" [here](https://groups.google.com/d/msg/kubernetes-dev/YawXYxGHWEg/IlLN-iD6CgAJ); we've been asked to provide a shorter summary here. + +This election is critical. The steering committee is not an honorary position; +it has effectively unlimited powers. Serving is a duty, not a privilege, and I +humbly ask for your vote. + +--- + +I have been involved with Kubernetes since before 1.0, primarily on AWS support +(I am a lead of sig-aws), but also contributed the original multi-zone & +NodePort support. I also started the kops project, to produce an open-source +and consistent Kubernetes installation tool. I'm an independent, working with +Kubernetes in my day job but not employed to contribute to it, so I contribute +instead where I see a problem or an unmet need. + +If elected, I will serve wearing my own two hats: that of a developer on +the project contributing because it is a positive personal experience, and that +of an end-user of Kubernetes valuing a stable and straightforward product. + +I believe I bring particularly strong experience on non-GCE, non-Redhat +platforms, and on the realities of maintaining projects outside the core repo. +I think these are likely to be some of the most challenging areas for the +steering committee. + +## My manifesto: + +(Abbreviated from [here](https://groups.google.com/d/msg/kubernetes-dev/YawXYxGHWEg/IlLN-iD6CgAJ) ) + +* Reach decisions quickly & consistently; communicate them clearly. + +* Value a clear and efficient developer process. + +* Empower the release team with the goal of producing a more stable release. + +* Figure out how to delegate to SIGs without creating fiefdoms. + +* Streamline our processes. + +* Promote experimentation with alternative processes amongst our many projects, +balancing against the need for a consistent experience, allow the best approaches to "bubble-up". + diff --git a/events/elections/README.md b/events/elections/README.md new file mode 100644 index 00000000..14a1ea3f --- /dev/null +++ b/events/elections/README.md @@ -0,0 +1,96 @@ +## Kubernetes Elections + +This document will outline how to conduct a Kubernetes Steering Committee Election. See the [Steering Committee Charter](https://git.k8s.io/steering/charter.md) for more information of how the committee decides when to have an election, the method, and the maximal representation. + +## Steering Committee chooses Election Deadlines and Officers + +- Steering Committee selects the Election Officers +- Dates should be in UTC time, use a [world clock service](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Election+Test&iso=20181101T00&p1=%3A&ah=10) in documentation and email announcements so that end users see the correct time and date based on where they live. + + +### SC Selects the following dates: + +- Recommend the month of October to not collide with a release or end of a quarter. +- Nomination and Voter Registration period start +- Nomination period end (At least a two week period) +- Voter Registration Deadline +- Link to voter registration process (doesn’t exist yet) +- Election period start + - It takes time to create the poll in CIVS, so don’t give a specific hour, instead say “Morning of the 10th” or something vague. +- Election period stop + - CIVS needs to be manually stopped, so an actual person needs to click for the poll to stop, so this needs to be a human friendly time. +- Results announcement date + +## Process + +1. Election officers prepare the election repository + - Make github.com/kubernetes/community/elections/$YEAR + - Make github.com/kubernetes/community/elections/$YEAR/README.md, this is the voter’s guide. + - Copy over the voter’s guide from the previous year. The voter’s guide is the single source of truth for the election that year! All announcements and notices should link to this document. + - Update with new dates, candidates, and procedures (if necessary). + - Announce to the candidates to submit PRs with their platform statement (if they desire), 300 word limit. Each platform document lives in the elections/$YEAR directory, with the voter’s guide (README.md) acting as the index. + +2. Announce voting schedule to community + +- Should mostly be links to the voter guide and the Steering Committee Charter +- On kubernetes-dev list, kubernetes-dev slack, and twitter + +3. Executing the Election in CIVS + +- Use [CIVS](http://civs.cs.cornell.edu/civs_create.html) to create the election, which CIVS calls a poll. Once you send out the ballots you cannot UNSEND the emails, ensure everything in the form is correct! +- Name of the poll - “Kubernetes Steering Committee Election for $YEAR” +- Name of supervisor - “Kubernetes Steering Committee” +- Email - elections@kubernetes.io : Googlegroups doesn’t work here. This mail should resolve to members of the steering committee AND the election officers. +- Date and Time: Write in the date and time the election will stop. This field is not programmatic, the election is stopped by hand, so you can write this in plain text. +- Description: This election is to nominate the steering committee for the Kubernetes project. Select the three(3) candidates, by order of preference. Please see the voter's guide for more information. PLEASE NOTE: "No opinion" is also a voting option if you do not feel comfortable ranking every single candidate. +- Add the candidate list to the form +- How many choices will win: This number needs to be set to the amount of open seats of a given election +- More options, check the boxes for: + - Do not release results to all voters. + - Enable detailed ballot reporting. + - Allow voters to select “no opinion” for some choices. +- Click create poll, this will send elections@kubernetes.io an email with instructions. +- It will send you a link to “Poll Control”, bookmark this generated page as this is where you will add voters and also resend ballots to people if their ballot gets lost or filtered. +- This page is where the “Start Poll” and “Stop Poll” buttons are, start the poll. +- Paste in the registered voters and click add voters. + - It will mail the ballots to the participants. + - It does duplicate detection so multiple entries are fine. +- Leave the poll open for the duration of voting. + - Remember to send a 24 hour reminder before closing the poll. + +## Roles and Responsibilities: + +### Steering Committee + +- Select election dates +- Select Election Officers +- Select criteria for Kubernetes Members of Standing +- Must refrain from endorsing or otherwise advocating for any candidate +- Is allowed to vote in the election +- Announces results of the election to the community +- Commit the results of the election to the Kubernetes Community repository + +### Election Officers + +- Must be a Kubernetes Member of Standing +- Cannot be running for office in the current election +- Cannot be a current member of the steering committee +- Generates the voter guide +- Tracks candidates +- Monitors kubernetes-dev for nominations + - Keeps track of nominees in a spreadsheet + - Ensures that each nominee has the required nominations from three different employers (as stated in the charter) + - All nominations are conducted in the public, so sharing this sheet during the nomination process is encouraged +- Accepts/Reviews pull requests for the candidate platforms + - The community generally assists in helping with PRs to give the candidates a quick response time +- Update the community regularly via the community meeting +- Post on behalf of the steering committee if necessary +- Posting deadlines and reminders to kubernetes-dev, twitter, and slack. +- Reissues ballots from CIVS to voters who might have not received their ballot. +- Miscellaneous election related tasks as decided by the steering committee. +- Must refrain from endorsing or otherwise advocating for any candidate. +- Must refrain from discussing the election specifics during the election period. +- Guard the privacy of the email addresses of voters +- It is impossible for the election officers to see the results of the election until the election ends; for purposes of transparency with the community it is encouraged to release some statistics during the election (ie. “65% of the community has voted so far!”) +- Ensure that the election results are handed over to the steering committee. +- Is allowed to vote in the election \ No newline at end of file diff --git a/events/office-hours.md b/events/office-hours.md new file mode 100644 index 00000000..3d7aa8c8 --- /dev/null +++ b/events/office-hours.md @@ -0,0 +1,76 @@ +# Kubernetes Community Office Hours + +## UPDATE: NO OFFICE HOURS UNTIL 2018, Happy Holidays! + +Office Hours is a live stream where we answer live questions about Kubernetes from **users** on the [YouTube channel](https://www.youtube.com/c/KubernetesCommunity/). Office hours are a regularly scheduled meeting where people can bring topics to discuss with the greater community. They are great for answering questions, getting feedback on how you’re using Kubernetes, or to just passively learn by following along. + +**Special Pilot Edition - Contributor Office Hours** +This special office hours pilot will cater to upstream Kubernetes contributors with one off questions being answered from current members of standing with the project. + +Example Questions: +What SIG do I join? +What to do when there is a lot of back and forth on an issue? +What's going on with the tests? +...bring these questions live or to the #office-hours slack channel + +Pilot will take place: +Nov 29th, 2017 at 9am PST / 17:00 UTC on Zoom: https://zoom.us/j/921352437 +If the pilot does well, we will update this with further information including the regular schedule of sessions. + +### When and Where + +Third Wednesday of every month, there are two sessions: + +- European Edition: [2pm UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Kubernetes+Office+Hours+%28European+Edition%29&iso=20171115T14&p1=136&ah=1) +- Western Edition: [9pm UTC](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Kubernetes+Office+Hours+%28Western+Edition%29&iso=20171115T13&p1=1241) + +Tune into the [Kubernetes YouTube Channel](https://www.youtube.com/c/KubernetesCommunity/live) to follow along. + +You can post questions on the [#office-hours channel](https://kubernetes.slack.com/messages/office-hours) on Slack, or if you like you can submit your question to Stack Overflow and have us take a look. + +### How it Works + +#### Bringing your own Stack Overflow Question + +If you submit a [SO question](https://stackoverflow.com/questions/tagged/kubernetes) we can prepare ahead of time and check important details. + +As a thanks to the community the person asking the question can then ensure that a well written answer makes it way to the question afterwards so that we can build a knowledge base and help maintain the incoming questions. We can also use the video archive of each meeting to bring context to each SO question we answer. + +Questions that aren’t addressed or need work can be punted to the next week or we can encourage other people to give them a look, at a bare minimum we can at least help socialize the difficult questions. We keep a backlog of open questions in the [meeting notes](http://bit.ly/k8s-office-hours-notes). + +The hosts will do a shout out of thanks to the [current leaderboard](https://stackoverflow.com/tags/kubernetes/topusers) of SO answerers each meeting so the people helping answer questions can get some recognition. + +#### What’s Ontopic + +Specific questions about Kubernetes as pertaining to the topic. Since this is a Q&A format, we’d like questions that can be answered generally. So for example: + +- Bad: My ingress configuration is broken please fix it. (Dependent on local configuration) +- Good: My ingress configuration is broken can you discuss what problems you usually see and common mistakes that people make so I can avoid them? (Generalized and can communicate things that can help multiple people) +- Bad: How do I deploy my application in Kubernetes? (Easy to look up, tons of content on this) +- Good: What best practice techniques are there for deploying applications in Kubernetes? (Nuanced version lets us cover RBAC, application lifecycle) +- Bad: My pods aren’t coming up on a node. (Vague) +- Good: My pods aren’t coming up or misbehaving, what are the debugging steps to find out the root cause? (Helps us communicate the thought process for debugging to a general audience) + +#### What’s Offtopic + +Local installation and debugging: The participants don’t have access to your network or your hardware. The host can/should help the user transform a vague question into something answerable and reusable. + +Let’s try to not just dismiss bad questions outright, but use it as an opportunity for the answer to be a teaching tool as opposed to just answering “It’s in /var/log/foo, next question.” If the question is about logging then the developers might as well share their experiences in that area, recommend tools, share an anecdote, things of that nature. + + +### Archives + +Archives of all the sessions are kept here: + +- [Office Hours playlist](https://www.youtube.com/watch?v=D0Q7wwljN30&list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg) +- [Office Hours meeting notes](http://bit.ly/k8s-office-hours-notes) + + +### Volunteering + +We're always looking for volunteers to host and answer questions. Volunteers looking to host hours in +more time zones are also welcome to join in and help us expand. + +- [Volunteer working sheet](http://bit.ly/k8s-office-hours-volunteers) + +If you have any questions ping [@castrojo](https://github.com/castrojo). -- cgit v1.2.3 From c7adce74ed48ee527c413183be80ff921b90c9fd Mon Sep 17 00:00:00 2001 From: Paris Date: Wed, 27 Dec 2017 18:40:03 -0800 Subject: Update communication.md --- communication.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/communication.md b/communication.md index 66c4beb3..8cd7dd24 100644 --- a/communication.md +++ b/communication.md @@ -19,16 +19,16 @@ and meetings devoted to Kubernetes. ## Social Media -* [Twitter](https://twitter.com/kubernetesio) -* [Blog](http://blog.kubernetes.io/) -* Pose questions and help answer them on [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes). -* [Slack](slack.k8s.io) - sign up +* [Twitter] +* [Blog] +* Pose questions and help answer them on [Stack Overflow]. +* [Slack] - sign up Real time discussion at kubernetes.slack.io: Discussions on most channels are archived at [kubernetes.slackarchive.io]. Start archiving by inviting the _slackarchive_ bot to a channel via `/invite @slackarchive`. -To add new channels, contact one of the [admins] in the #slack-admins channel. Our guidelines are [here](/communication/slack-guidelines.md). +To add new channels, contact one of the admins in the #slack-admins channel. Our guidelines are [here](/communication/slack-guidelines.md). ## Issues @@ -71,7 +71,7 @@ please propose a specific date on the [Kubernetes Community Meeting Agenda]. Kubernetes is the main focus of CloudNativeCon/KubeCon, held every spring in Europe and winter in North America. Information about these and other community events is available on the CNCF [events] pages. -[blog]: http://blog.kubernetes.io +[Blog]: http://blog.kubernetes.io [calendar.google.com]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles [CNCF code of conduct]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md [communication]: /communication.md @@ -86,8 +86,8 @@ Kubernetes is the main focus of CloudNativeCon/KubeCon, held every spring in Eur [kubernetes-users]: https://groups.google.com/forum/#!forum/kubernetes-users [kubernetes.slackarchive.io]: http://kubernetes.slackarchive.io [kubernetes.slack.com]: http://kubernetes.slack.com +[Slack]: slack.k8s.io [Special Interest Group]: /README.md#SIGs -[slack.k8s.io]: http://slack.k8s.io [Stack Overflow]: http://stackoverflow.com/questions/tagged/kubernetes [timezone table]: https://www.google.com/search?q=1000+am+in+pst [troubleshooting guide]: http://kubernetes.io/docs/troubleshooting -- cgit v1.2.3 From ad22d7b749282129ecd9d0925e1392dfff717773 Mon Sep 17 00:00:00 2001 From: Paris Date: Thu, 28 Dec 2017 10:13:17 -0800 Subject: update communication.md fixed links --- communication.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/communication.md b/communication.md index 8cd7dd24..395f7692 100644 --- a/communication.md +++ b/communication.md @@ -84,8 +84,8 @@ Kubernetes is the main focus of CloudNativeCon/KubeCon, held every spring in Eur [kubernetes-community-video-chat]: https://groups.google.com/forum/#!forum/kubernetes-community-video-chat [kubernetes-dev]: https://groups.google.com/forum/#!forum/kubernetes-dev [kubernetes-users]: https://groups.google.com/forum/#!forum/kubernetes-users -[kubernetes.slackarchive.io]: http://kubernetes.slackarchive.io -[kubernetes.slack.com]: http://kubernetes.slack.com +[kubernetes.slackarchive.io]: https://kubernetes.slackarchive.io +[kubernetes.slack.com]: https://kubernetes.slack.com [Slack]: slack.k8s.io [Special Interest Group]: /README.md#SIGs [Stack Overflow]: http://stackoverflow.com/questions/tagged/kubernetes -- cgit v1.2.3 From c1a8d8e5f3a0f6523e8a73e5914f61f3005b4a45 Mon Sep 17 00:00:00 2001 From: Paris Date: Thu, 28 Dec 2017 10:45:53 -0800 Subject: update communication.md fixed broken office hours link --- communication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/communication.md b/communication.md index 395f7692..37c3c2af 100644 --- a/communication.md +++ b/communication.md @@ -49,7 +49,7 @@ Users trade notes on the Google group ## Office Hours -Office hours are held once a month. Please refer to [this document](community/office-hours.md) to learn more. +Office hours are held once a month. Please refer to [this document](events/office-hours.md) to learn more. ## Weekly Meeting -- cgit v1.2.3