New�Contributor Workshop

Kubernetes Contributor Summit

Shanghai 2018

China Cup Publicity Image, used with permission

Captain�K8S

Who is this for?

You’re an advanced user and looking at contributing, or

You’ve contributed one patch/issue but want to know more, or

You’ve just gotten a job that involves heavy Kubernetes work, or

Some bug is driving you crazy and you want to fix it.

Mentors

Tim Pepper�SIG-Release�VMWare��Puja Abbassi�Giant Swarm�

Peter Zhao�ZTE

��

Josh Berkus�SIG-Release�Red Hat

Yang Li�SIG-Release�The Plant��Noah Abrahams�SIG-Contributor-Experience�Infosiftr

​

More Mentors

Brad Topol�SIG-Documentation�IBM��Zach Corleissen SIG-Documentation��

Sen Lu�SIG-Test-Infrastructure�Google

​

Order of Operations

• Introduction
• CLA signing
• Where to Contribute
• Communication
• The SIG system
• Tour of Repos

• Issues
• PRs
• Test Infrastructure
• Doc Contributions
• Local Build & Test
• Releases
• Going Beyond

Owner

Set priorities and approve proposals for subproject

Responsibility and leadership for entire repository/directory

Approver

Approve contributions for acceptance

Highly experienced reviewer and contributor in subproject

Reviewer

History of reviewing; reviews frequently

Authorship in subproject

Member

Active contributor to the project

Sponsored by two Reviewers

Non-member Contributors

CLA Signing

https://git.k8s.io/community/CLA.md

You will almost always want to go to the Individual Signup. You will choose “individual” vs “employee” on the next screen.

The sign-up.

It looks very similar.

When you need help with the CLA

​

The Linux Foundation helpdesk is friendly and responsive!

​

helpdesk@rt.linuxfoundation.org

Choose�Your Own�Adventure

Figuring out where to contribute

Why contribute to Kubernetes?

There are really only two motivations:

• You want to.�You are excited about the technology or the community and want to learn more.�
• You have to.�You need Kubernetes in some way, such as for your job.

Where to contribute?

Docs and Website

We strive for improving our docs at all times.

We can also use your help.

Frontend development

SIGs:�SIG-docs�SIG-contributor-experience

Testing

Our test-infra repository contains a variety of projects that implement our PR workflow and display test results, among other things

SIGs:�SIG-testing

Code

• Writing code
• Fixing bugs
• Reviewing code

​

SIGs:�Depends on your area of interest

Core Code

Kubernetes/kubernetes:

• Thousands of open issues
• Hundreds of open PRs
• Thousands of contributors
• Dozens of tests

Hard to get started with, but has a lot of structure.

​

Code: Subprojects & Drivers

Many smaller projects:

• Platforms & Cloud Providers
• Storage & Network drivers
• Developer tools (Helm, operators)
• UI & GUI tools

Smaller teams, can be easier to get started, but less structure & support.

Finding Your First Topic�or: Welcome to opensource!�

• You notice a bug
• You would like a feature
• You’re trying to learn a technology
• You want better documentation

Fitting Contributions�Into Your Job�

Goals Match:

• Something you/your team/your company wants fixed/improved/added

Skills Match:

• Find something where you have expertise to improve Kubernetes

Find Your Topic Exercise

• At your table, go around the table in a circle and explain (or speculate) on what part of Kubernetes you might want to contribute to.
• Also, explain what in your background, job, or interests motivates you.

Let’s Talk

Communication in the�Kubernetes Community

Standards of Communication�or: Why is everyone so nice?

We believe that mutual respect is a prerequisite for healthy collaboration.

​

https://git.k8s.io/community/code-of-conduct.md

https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/zh.md

​

That said...

…we do have some accepted traditions.

• Technical questions go on StackOverflow, Slack, or Discuss, not Github.�
• Github issues and pull requests often entail discussion related to the topic at hand. Stay courteous and follow up.�
• Stay patient as people may address your questions and contributions from all over the world.

Online Communications

• Slack
• discuss.kubernetes.io
• Mailing lists (Google Groups)
• Github PRs & Issues
• Meetings on Zoom

When in doubt, ask on Slack!

Good channels to start in are:

#cn-dev,

#cn-users,

#kubernetes-users,

#kubernetes-novice,

#sig-contribex

http://slack.k8s.io/

​

discuss.kubernetes.io

https://discuss.kubernetes.io/c/regional-discussions/china

Mailing lists

• One per SIG/WG
• (some used more than others)
• Run on GoogleGroups
• (access restrictions from China)
• You need to join:
• kubernetes-dev
• Required for Org Membership

Github

Github

Lots of discussion on PRs and issues.

Primary way to deal with change proposals, specifications, problems.

Make sure to follow-up and watch for questions/replies/bot notices!

BUT: many contributors don’t see notices

Zoom Meetings

Zoom Meetings

Schedule is on the community calendar

• SIG Meetings
• Weekly community meeting
• Special meetings

​

Don’t be afraid to ask about changing meeting times! (but also be understanding)

Other Communications

• Meet Our Contributors
• Monthly live video discussion with contributors
• Office Hours
• Kubecons
• Face-to-Face SIG meetings

Let’s Go Communicate!�(exercise)

​

• Join Discuss
• Join Slack
• Subscribe to kubernetes-dev
• Subscribe to the community calendar

links

Links from: https://kubernetes.io/community/�And https://contributor.kubernetes.io/

https://discuss.kubernetes.io

http://slack.k8s.io/

https://groups.google.com/forum/#!forum/kubernetes-dev

​

The SIG System

How work is organized

Special�Interest�Group

Semi-autonomous teams

• Own leaders & charter
• Responsible for code
• Own repo(s) (sometimes)
• Slack channel & mailing list
• Meetings (usually Zoom)
• Subprojects (& WGs)

List of SIGs in kubernetes/community repo�https://github.com/kubernetes/community/blob/master/sig-list.md

Types of SIGs

• Feature Areas
• Plumbing
• Cloud Providers
• Meta
• Docs

Feature Area SIGs

sig-auth

sig-apps

sig-autoscaling

sig-big-data

sig-cli

sig-multicluster

sig-network

​

sig-node

sig-scalability

sig-scheduling

sig-service-catalog

sig-storage

sig-ui

sig-windows

“Plumbing” SIGs

sig-api-machinery

sig-cluster-lifecycle

sig-instrumentation

​

Cloud Providers

sig-aws

sig-azure

sig-gcp

sig-ibmcloud

sig-openstack

sig-vmware

​

sig-cloud-provider

​

Meta

sig-architecture

sig-contributor-experience

sig-pm

sig-release

sig-testing

​

Documentation & Website

sig-docs

WGs and Subprojects

Working Groups: inter-SIG efforts

Subprojects: focus areas for SIGs (newer)

For specific:

• Tools (ex. Helm)
• Goals (ex. Resource Management)
• Areas (ex. Machine Learning)

WGs

wg-app-def

wg-apply

wg-container-identity

wg-iot-edge

wg-kubeadm-adoption

wg-machine-learning

​

wg-multitenancy

wg-policy

wg-resource-management

wg-security-audit

Subprojects

Usually found in kubernetes-sigs/ namespace

​

cloud tools

kustomize

kubebuilder

federation-v2

cri-o

contributor-site

Picking the right SIG

• Figure out what specific projects/areas you want to work on.
• Find out which SIG/WG/subproject covers that
• Ask on #sig-contribex
• Go to the SIG intros at this conference
• Join that SIG/subproject
• If joining a WG/subproject, also join a SIG

SIG Selection Exercise

https://github.com/kubernetes/community

Based on what you know, select a SIG where you would like to start contributing.

Each person go around the table and share this. Ask mentors for help selecting a SIG.

​

Tour of�Repositories

Repos being Refactored

Core Repository

kubernetes/kubernetes

Project

k/Community

k/Enhancements

k/Steering

k/Test-Infra

k/Perf-Tests

Docs/Website

k/website

​

Developer Tools

k/sample-controller*

k/sample-apiserver*

k/code-generator*

k/k8s.io

k/kubernetes-template-project

​

Staging Repos

api

apiextensions-apiserver

apimachinery

apiserver

client-go

​

​

code-generator

kube-aggregator

metrics

sample-apiserver

SIG repos

release

federation

autoscaler

​

… nobody else?

​

Cloud Providers

cloud-provider-azure

cloud-provider-gcp

cloud-provider-openstack

​

… where’s AWS?

​

​

​

Products & Tools

kubeadm

kubectl

kops

helm

charts

kompose

​

ingress-nginx

minikube

dashboard

heapster

kubernetes-anywhere

kube-openapi

​

kubernetes-sigs�subprojects

​

I’ve got 99 problems and Kube-Incubator is 22 of them

A Historical Accumulation

• Random stuff in kubernetes/
• Random stuff in kube-incubator/
• Random stuff in kubernetes/contrib/

​

… and no clear path for promotion/deprecation.

My repository, my rules

Repos can have different:

• Ownership
• Approval workflows
• Merge workflows
• Release cycles

Membership/Ownership

OWNERS files govern who approves code

They’re recursive to parent directories

… but some repos still use GitHub groups

… and some OWNERS files refer to groups

Issues and�Contributions

A problem statement is the start

First: Bug Reports

• Find the right repo for the bug
• Create a complete & detailed bug report
• Including labels!
• Follow up with commenters/fixers.

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

​

What happened:

When use an existing azure disk(also called static provisioning) in pod, if that disk has partitions, the disk will be formatted in the pod mounting.

How to reproduce it (as minimally and precisely as possible):

• create a disk with source from an os disk, e.g.

az disk create --name duposdisk --resource-group andy-mg110 --sku Standard_LRS --size-gb 30 --location westus2 --source https://xxx.blob.core.windows.net/osdisk/k8s-agentpool-33591117-0-osdisk.vhd�

• use disk static provioning for that copied disk
• kubectl exec -it nginx-azuredisk -- bash
• that disk is already formatted before pod could access it

Issues as Specifications

Most changes in Kubernetes start with an Issue:

• Feature proposals
• API change proposals
• New tests
• Additions to Docs
• Changes to community project management

From Issue to Code/Docs

• Start with an issue that proposes a change
• Apply all appropriate labels
• cc SIG leads and concerned devs
• Raise the issue at a SIG meeting or on the list
• When you have “lazy consensus”, submit a PR.

Required Labels

On creation:

sig/

kind/��Optional:

area/

Added later:

triage/

priority/

​

sig/ label

Defines which SIG the issue should belong to. Ask or guess if you don’t know.

sig/auth

sig/test-infrastructure

sig/api-machinery

sig/node

kind/ label

Defines what type of issue it is:

kind/bug kind/failing-test

kind/feature kind/flake

kind/documentation kind/cleanup

kind/design

​

​

triage/ label

For Issues that are being closed as part of triage.

triage/duplicate

triage/needs-information

triage/support

triage/unreproduceable

triage/unresolved

priority/ label

How critical is this issue?

priority/critical-urgent

priority/important-soon

priority/important-longterm

priority/backlog

priority/awaiting-evidence

area/ label

Optional label, may define specific focus within the SIG. No standardization.

area/kubectl

area/api

area/dns

area/platform/gce

help-wanted

• Currently mostly complicated things
• Some require special knowledge (yours?)

​

good first issue

• Vetted for new contributors
• Usually mentors are available

​

Following up

• Make sure you check issue for comments and respond.
• Try to test solutions.
• Discuss alternatives.
• Get Issue on SIG agendas and attend the meeting.

Issues Exercise

• Go to the contributor-playground repo:�https://github.com/kubernetes-sigs/contributor-playground
• Two people at the table file issues.
• Add labels to the issues:�/kind documentation�/sig contributor-experience

Issues Exercise

4. The other people at the table should� comment on the issue.��5. One of them should add:� /priority important-soon��6. The issue creator should respond to the comments.

Making Contributions�By Pull Request (PR)

A hands-on walk-through

The GitHub Workflow

Main Types of PRs

Bug Fix: PR to fix an already-known problem with an existing feature. kind/bug or kind/cleanup

Feature: PR to implement new functionality. kind/feature

KEP: tracking document that aggregates many feature PRs to implement large features. In the KEPs repo.

Approval Steps

• Submit
• Add labels & notes
• Bots say the PR is OK
• SIGs/Owners /approve
• Other contributors /lgtm
• Tests pass
• Tide merges the PR

More Labels

• lgtm:
• Looks Good To Me or “I’ve reviewed the PR”
• approved:
• OWNERS file approver says it’s merge ready
• release-note(-none):
• Does(not) need a release note
• size:
• How big is the PR? (set automatically)
• milestone:
• which release is this part of?

Finding a reviewer

• attach /sig label
• contact your mentor(s)
• contact the SIG
• attend SIG meeting
• Slack
• contact Owners

Following up

• Make sure to answer questions by reviewers!
• Look for messages from bots
• Seek out any additional Owners you need to approve
• Read code comments, change your code if there is consensus

Different reviewers will have different opinions, don't be afraid to ask for clarification.

On you: Rebasing, Test Fails

needs-rebase: your submission now conflicts with master, needs to be rebased

test failures: the bot will tell you a test has failed, you need to investigate & troubleshoot

​

PR Exercise

• Everyone fork and clone the repo:�https://github.com/kubernetes-sigs/contributor-playground
• CLA signed individuals can create a PR
• We will follow some of those PRs live
• Anyone can review/comment/rebase
• Pay attention to labels and bot prompts

Test Infrastructure

How bots tell you when you mess up

PR author must have signed CLA

PR must pass tests

PR must be approved

PR must be mergeable

Merge commit must pass tests

PR Workflow

PR author must have signed CLA

PR must pass tests

PR must be approved

PR must be mergeable

Merge commit must pass tests

PR Workflow

PR author must have signed CLA

PR must pass tests

PR must be approved

PR must be mergeable

Merge commit must pass tests

PR Workflow

PR author must have signed CLA

PR must pass tests

PR must be approved

PR must be mergeable

Merge commit must pass tests

PR Workflow

PR author must have signed CLA

PR must pass tests

PR must be approved

PR must be mergeable

Merge commit must pass tests

PR Workflow

PR author must have signed CLA

PR must pass tests

PR must be approved

PR must be mergeable

Merge commit must pass tests

PR Workflow

Tide

PR dashboard�Current status of all your PRs (prow.k8s.io/pr)

Contribute to test-infra�Anyone can contribute to test-infra!�Send PRs to kubernetes/test-infra!�������Have questions? Contact us at following slack channel:��#sig-testing�#prow��Or mail to kubernetes-sig-testing@googlegroups.com

Documentation

github.com/kubernetes/website

​

@zacharysarah

​

Anyone can contribute to docs.

Kubernetes docs

Website URL: https://kubernetes.io

​

GitHub repository: kubernetes/website

​

K8s slack: #sig-docs

​

​

Working with docs

Docs use the Kubernetes bot!

​

To update current docs, branch from master.

​

To create docs for a specific release, branch from release-1.X.

Anyone can contribute to docs.

Local Build & Test

For code contributors

Development Environment

• Have:
• lots of RAM and CPU
• multiple 10’s of GB’s disk
• Use Linux
• Place k8s git repo fork in:
• $GOPATH/src/k8s.io/kubernetes

​

​

• Start thinking about what you might use for a test cluster

Building

• Go!
• So (un)naturally you do:
• cd kubernetes/
• ./build/run.sh make
• Many variants:
• make WHAT=‘cmd/kubectl’
• Whaaat?

​

​

• Also this build happens…in a linux container!

Testing with Minikube

• https://github.com/kubernetes/minikube/
• A kubernetes cluster-in-a-VM on your local machine!
• Requirements:
• host machine with kubectl
• guest VM ability
• host<->guest networking and internet connectivity

Releases

Software has to leave home eventually

The 3-month Release Cycle

Phases

Feature: work on spec/details of new features.

Development: complete those features:

Code Slush/Freeze: fix bugs and stabilize.

​

… but real work spans several release cycles.

Going Beyond �This Workshop

What’s next for you?

This conference

• Sessions
• SIG Intros
• SIG Deep Dives
• Hallway Track

​

Membership will affect your pull request workflow and remove some of the obstacles.

We also really want you to become members.��Here’s why.

Owner

Set priorities and approve proposals for subproject

Responsibility and leadership for entire repository

Approver

Approve contributions for acceptance

Highly experienced reviewer and contributor in subproject

Reviewer

History of reviewing; reviews frequently

Authorship in subproject

Member

Active contributor to the project

Sponsored by two Reviewers

Non-member Contributors

Getting Org Membership

Once you’ve

• Made one PR contribution, OR
• Joined a team

Then you should:

• Get two sponsors
• File an issue against kubernetes/org and apply.

Meetups!

Join a Kubernetes meetup!

​

​

​

​

China has meetups in: Beijing, Chengdu, Guangzhou, Hangzhou, Nanjing, Shanghai, and Shenzen. Also, meetups in Hanoi, Hong Kong, Seoul, Singapore, Taipei, Tokyo, and more!

CNCF Ambassadors

No meetups in your area? Start one.

CNCF and Ambassadors across Asia can help.

China has 6 Ambassadors (4 in Beijing, 1 in Hangzhou, 1 in Xi’an)

India has 3 (2 in Hyderabad, 1 in Bengaluru), Singapore has 2, Japan, Australia, and South Korea each have 1

Mentoring Opportunities

• Meet-Our-Contributors
• Monthly, online contributor help
• Group Mentoring
• To train new reviewers
• Release Team Shadow
• Good way to learn a lot about the project
• 1-on-1 ad-hoc mentoring
• GSOC/Outreachy
• If you qualify

Kubernetes Tutorials

• As an operator
• As an app developer
• As a kubernetes developer

Other Contributions

• Answering Questions on StackOverflow
• Github Repo Management
• Blogging, Evangelism, and Promotion
• Event Management and Volunteering
• Visual Communication
• User Experience Feedback and Surveys
• Helping Manage Youtube Recordings
• ...and more!

Thank you!

And welcome aboard!

Getting Help

Slack:

• #cn-dev
• #kubernetes-users
• #sig-contribex

discuss.kubernetes.io:

• #contributors

​

​

Meet Our Contributors events��

Copyright & Licensing

Copyright 2018 The Kubernetes Project and associated contributors, including Josh Berkus, Guinevere Saenger, Puja Abbassi, Tim Pepper, Sen Lu, Yang Li, Xiang Peng Zhao, Zach Corleissen, Noah Kantrowitz, Noah Abrahams, and other contributors. Trademarks and logos used in the presentation are property of their respective owners.

This presentation in all of its forms may be copied and distributed under the terms of the Creative Commons Attribution License 4.0

​

​