Update contributing docs (#870)

Signed-off-by: FillZpp <FillZpp.pub@gmail.com>

.github/ISSUE_TEMPLATE/bug-report.md

@@ -20,7 +20,5 @@ assignees: FillZpp
 **Environment**:
 - Kruise version:
 - Kubernetes version (use `kubectl version`):
-- OS (e.g: `cat /etc/os-release`):
-- Kernel (e.g. `uname -a`):
-- Install tools:
+- Install details (e.g. helm install args):
 - Others:

.github/ISSUE_TEMPLATE/feature-request.md

@@ -3,7 +3,7 @@ name: Feature Request
 about: Suggest an idea for this project
 title: "[feature request]"
 labels: kind/feature-request
-assignees: jian-he
+assignees: FillZpp
 
 ---
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -8,13 +8,8 @@ https://github.com/openkruise/kruise/blob/master/CONTRIBUTING.md -->
 ### Ⅱ. Does this pull request fix one issue?
 <!--If so, add "fixes #xxxx" below in the next line, for example, fixes #15. Otherwise, add "NONE" -->
 
+### Ⅲ. Describe how to verify it
 
-### Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
-
-
-### Ⅳ. Describe how to verify it
-
-
-### Ⅴ. Special notes for reviews
 
+### Ⅳ. Special notes for reviews
 

.github/workflows/ci.yaml

@@ -61,7 +61,7 @@ jobs:
       - name: Run shellcheck
         run: find ./ -name "*.sh" | grep -v vendor | xargs shellcheck
       - name: Lint markdown files
-        run: find  ./ -name  "*.md" | grep -v vendor | grep -v commandline |  grep -v .github |  grep -v swagger |  grep -v api |  xargs mdl -r ~MD010,~MD013,~MD022,~MD024,~MD029,~MD031,~MD032,~MD033,~MD036
+        run: find  ./ -name  "*.md" | grep -v vendor | grep -v commandline |  grep -v .github |  grep -v swagger |  grep -v api |  xargs mdl -r ~MD010,~MD013,~MD014,~MD022,~MD024,~MD029,~MD031,~MD032,~MD033,~MD036
 #      - name: Check markdown links
 #        run: |
 #          set +e

CONTRIBUTING.md

@@ -88,25 +88,29 @@ We encourage contributors to follow the [PR template](./.github/PULL_REQUEST_TEM
 As a contributor, if you want to make any contribution to Kruise project, we should reach an agreement on the version of tools used in the development environment.
 Here are some dependents with specific version:
 
-- Golang : v1.13+ (1.15 is best)
+- Golang : v1.15+ (1.17 is best)
 - Kubernetes: v1.16+
 
 ### Developing guide
 
 There's a `Makefile` in the root folder which describes the options to build and install. Here are some common ones:
 
 ```bash
+# Generate code and manifests e.g. CRD, RBAC YAML files etc
+make manifests
+
 # Build the controller manager binary
 make build
 
 # Run the unit tests
 make test
-
-# Generate manifests e.g. CRD, RBAC YAML files etc
-make manifests
 ```
 
-**If you want to start kruise-controller-manager locally to work with a Kubernetes cluster, you should follow the [debug guide](./docs/debug/README.md).**
+**There are some guide documents for contributors in [./docs/contributing/](./docs/contributing), such as debug guide to help you test your own branch in a Kubernetes cluster.**
+
+### Proposals
+
+If you are going to contribute a feature with new API or needs significant effort, please submit a proposal in [./docs/proposals/](./docs/proposals) first.
 
 ## Engage to help anything
 
@@ -127,20 +131,4 @@ In a word, **ANY HELP IS CONTRIBUTION**.
 ## Join Openkruise as a member
 
 It is also welcomed to join Openkruise team if you are willing to participate in Openkruise community continuously and keep active.
-
-### Requirements
-
-- Have read the [Contributing to Openkruise](./CONTRIBUTING.md) carefully
-- Have read the [Contributor Covenant Code of Conduct](./CODE_OF_CONDUCT.md)
-- Have submitted multi PRs to the community
-- Be active in the community, may including but not limited
-  - Submitting or commenting on issues
-  - Contributing PRs to the community
-  - Reviewing PRs in the community
-
-### How to do it
-
-You can do it in either of two ways:
-
-- Submit a PR in the project repo
-- Contact via the [community](./README.md#community) channels offline
+Please read and follow the [Community Membership](https://github.com/openkruise/community/blob/master/community-membership.md).

Dockerfile

@@ -1,5 +1,5 @@
 # Build the manager binary
-FROM golang:1.16 as builder
+FROM golang:1.17 as builder
 
 WORKDIR /workspace
 # Copy the Go Modules manifests

Makefile

@@ -55,7 +55,7 @@ build: generate fmt vet manifests ## Build manager binary.
 run: manifests generate fmt vet ## Run a controller from your host.
 	go run ./main.go
 
-docker-build: test ## Build docker image with the manager.
+docker-build: generate fmt vet manifests ## Build docker image with the manager.
 	docker build --pull --no-cache . -t ${IMG}
 
 docker-push: ## Push docker image with the manager.

docs/contributing/BUMP_KUBERNETS_VERSION.md

@@ -0,0 +1,55 @@
+# Bump Kubernetes version
+
+## Preparing: Compatibility matrix
+
+| kubebuilder | controller-runtime | Kubernetes  |
+|-------------|--------------------|-------------|
+| 1.x         | 0.1.x              | 1.13        |
+| 2.x         | 0.2.x ~ 0.6.x      | 1.14 ~ 1.18 |
+| 3.x         | 0.7.x ~ ?          | 1.19 ~ ?    |
+
+Which means the correspondence between controller-runtime and Kubernetes:
+
+- controller-runtime v0.7  - Kubernetes v1.19
+- controller-runtime v0.8  - Kubernetes v1.20
+- controller-runtime v0.9  - Kubernetes v1.21
+- controller-runtime v0.10 - Kubernetes v1.22
+- ...
+
+So, you should firstly make sure your local kubebuilder is 3.x,
+and make clear which versions of Kubernetes and controller-runtime you are going to update.
+
+Usually we bump them every two versions with the even minor version, such as Kubernetes 1.20, 1.22.
+
+## Actions
+
+### Step 1: update dependencies in go.mod
+
+- Bump `k8s.io/kubernetes` to `v1.x.y`.
+- Bump `k8s.io/xxx` in require and replace to `v0.x.y`, except `k8s.io/kube-openapi` and `k8s.io/utils`, you can ignore them for now.
+- Bump `sigs.k8s.io/controller-runtime` to matched version with Kubernetes.
+
+Tidy them and download:
+
+```shell
+$ go mod tidy
+
+$ go mod vendor
+```
+
+### Step 2: solve incompatible problems
+
+Build and test:
+
+```shell
+$ make build test
+```
+
+Solve all incompatible problems in the project.
+
+### Step 3: fetch upstream changes of StatefulSet and DaemonSet
+
+We hope the Advanced StatefulSet and Advanced DaemonSet in Kruise should be compatible with the upstream ones.
+So you should look for the upstream changes and fetch them into Kruise.
+
+This can be done in next individual PRs to make this bump-version-PR more clear and readable.

docs/debug/README.md → docs/contributing/DEBUG.md

@@ -35,28 +35,25 @@ minikube start
 ```
 
 ### Second Step: Deploy your kruise with a deployment
-The followings are the steps to debug Kruise controller manager locally using Pod. Note that the
-`WEBHOOK_HOST` env variable should be unset if you have tried [above](#way-2-debug-your-kruise-locally)
-debugging methodology before.
-#### 1.Build controller-manager and CRDs
-Make your own code changes and validate the build by running `make build` and `make manifests` in Kruise directory.
-#### 2.Deploy customized controller manager
-The deployment can be done by following steps assuming a fresh environment.
-Note that the new controller manager will be deployed via a `Deployment` to replace the default Kruise controller manager.
-- Prerequisites: create new/use existing [dock hub](https://hub.docker.com/) account ($DOCKERID), and create a `kruise` repository in it;
-- step 1: `docker login` with the $DOCKERID account;
-- step 2: `export IMG=<image_name>` to specify the target image name. e.g., `export IMG=$DOCKERID/kruise:test`;
-- step 3: `make docker-build` to build the image locally;
-- step 4: `make docker-push` to push the image to dock hub under the `kruise` repository;
-- step 5: `export KUBECONFIG=<your_k8s_config>` to specify the k8s cluster config. e.g., `export KUBECONFIG=$~/.kube/config`;
-- step 6: `make deploy IMG=${IMG}` to deploy your kruise-controller-manager to the k8s cluster;
+#### 1. Generate code and manifests in your branch
+Make your own code changes and validate the build by running `make generate manifests` in Kruise directory.
+#### 2. Deploy customized controller manager
+The deployment can be done by following steps.
+- Prerequisites: prepare a `kruise` repository in an image registry, it can be [docker hub](https://hub.docker.com/) or your private hub.
+- step 1: `export IMG=<image_name>` to specify the target image name. e.g., `export IMG=$DOCKERID/kruise:test`;
+- step 2: `make docker-build` to build the image locally and `make docker-push` to push the image to registry;
+- step 3: `export KUBECONFIG=<your_k8s_config>` to specify the k8s cluster config. e.g., `export KUBECONFIG=$~/.kube/config`;
+- step 4:
+  - 4.1: `make deploy` to deploy Kruise to the k8s cluster with the `IMG` you have packaged, if the cluster has not installed Kruise or has installed via `make deploy`;
+  - 4.2: if the cluster has installed Kruise via helm chart, we suggest you just update your `IMG` into it with `kubectl set image -n kruise-system deployment kruise-controller-manager manager=${IMG}`;
 
 Tips:
-- If you need to update `mutatingwebhookconfiguration` or `validatingwebhookconfiguration` of kruise, please run `./scripts/uninstall.sh` in Kruise directory to uninstall them `before step 6`.
+- You have to run `./scripts/uninstall.sh` to uninstall Kruise if you installed it using `make deploy`.
 
 #### 3.View logs of your kruise
 You can perform manual tests and use `kubectl logs -n kruise-system <kruise-controller-manager-pod-name>` to check controller logs for debugging, and you can see your `<kruise-controller-manager-pod-name>` by applying `kubectl get pod -n kruise-system`.
-## Way 2: Debug your kruise locally
+
+## Way 2: Debug your kruise locally (NOT Recommended)
 Kubebuilder default `make run` does not work for webhooks since its scaffolding code starts webhook server
 using kubernetes service and the service usually does not work in local dev environment.
 
@@ -78,4 +75,4 @@ export WEBHOOK_HOST=${YOUR_LOCAL_IP}
 
 make install
 make run
-```
+```

hack/tools.go

@@ -1,3 +1,4 @@
+//go:build tools
 // +build tools
 
 /*
@@ -20,7 +21,7 @@ limitations under the License.
 package hack
 
 import (
-	_ "github.com/go-bindata/go-bindata"
+	_ "github.com/go-bindata/go-bindata/go-bindata"
 	_ "k8s.io/code-generator"
 	_ "k8s.io/kube-openapi/cmd/openapi-gen"
 )

pkg/util/inplaceupdate/inplace_update_defaults.go

@@ -267,7 +267,7 @@ func checkAllContainersHashConsistent(pod *v1.Pod, runtimeContainerMetaSet *apps
 		switch hashType {
 		case plainHash:
 			if expectedHash := kubeletcontainer.HashContainer(containerSpec); containerMeta.Hashes.PlainHash != expectedHash {
-				klog.Warningf("Find container %s in runtime-container-meta for Pod %s/%s has different plain hash with spec %s != %s",
+				klog.Warningf("Find container %s in runtime-container-meta for Pod %s/%s has different plain hash with spec %v != %v",
 					containerSpec.Name, pod.Namespace, pod.Name, containerMeta.Hashes.PlainHash, expectedHash)
 				return false
 			}

scripts/generate_bindata.sh

@@ -24,7 +24,7 @@ export E2E_ROOT
 echo "$E2E_ROOT"
 
 # Install tools we need, but only from vendor/...
-go get github.com/go-bindata/go-bindata/go-bindata
+go install github.com/go-bindata/go-bindata/go-bindata
 
 # run the generation from the root directory for stable output
 pushd "${E2E_ROOT}" >/dev/null