Bug 1873043: Rebase to 1.19.2

OWNERS

@@ -3,25 +3,22 @@
 filters:
   ".*":
     reviewers:
-    - bparees
     - deads2k
-    - sjenning
-    - smarterclayton
+    - sttts
     - soltysh
-    - tbielawa
+    - mfojtik
+    - marun
+    - tnozicka
+
+    # approvers are limited to the team that manages rebases and pays the price for carries that are introduced
     approvers:
-    - bparees
     - deads2k
-    - derekwaynecarr
-    - eparis
-    - knobunc  # Network, Multi-cluster, Storage
-    - mfojtik
-    - pweil-
-    - sjenning
-    - soltysh
     - sttts
-    - smarterclayton
-    - tbielawa # also for build and automated release tooling changes
+    - soltysh
+    - mfojtik
+    - marun
+    - tnozicka
+
   "^\\.go.(mod|sum)$":
     labels:
     - "vendor-update"

README.openshift.md

@@ -11,7 +11,7 @@ any code you have in upstream Kubernetes will land in Openshift via
 this mechanism.
 
 2. Cherry-picked patches for important *bug fixes*.  We really try to
-limit feature back-porting entirely.
+limit feature back-porting entirely. Unless there are exceptional circumstances, your backport should at least be merged in kubernetes master branch. With every carry patch (not included in upstream) you are introducing a maintenance burden for the team managing rebases.
 
 ### For Openshift newcomers: Pick my Kubernetes fix into Openshift vs. wait for the next rebase?
 

REBASE.openshift.md

@@ -51,9 +51,12 @@ git remote add --fetch openshift https://github.com/openshift/kubernetes
 git checkout -b rebase-1.20.0 v1.20.0
 ```
 
-- Merge the targeted `openshift/kubernetes` branch (e.g. `master`) with
-  strategy `ours` to reset the the branch to the targeted release tag without
-  involving manual conflict resolution.
+- Merge `openshift(master)` branch into the `rebase-1.20.0` branch with merge 
+  strategy `ours`. It discards all changes from the other branch (`openshift/master`) 
+  and create a merge commit. This leaves the content of your branch unchanged,
+  and when you next merge with the other branch, Git will only consider changes made
+  from this point forward.  (Do not confuse this with `ours` conflict resolution 
+  strategy for `recursive` merge strategy, `-X` option.) 
 
 ```
 git merge -s ours openshift/master
@@ -62,24 +65,29 @@ git merge -s ours openshift/master
 ## Creating a spreadsheet of carry commits from the previous release
 
 Given the upstream tag (e.g. `v1.19.2`) of the most recent rebase and the name
-of the branch that is targeted for rebase (e.g. `master`), generate a csv file
+of the branch that is targeted for rebase (e.g. `openshift/master`), generate a tsv file
 containing the set of carry commits that need to be considered for picking:
 
 ```
-git log $( git merge-base master v1.19.2 )..master \
- --pretty=format:',%H,%s,https://github.com/openshift/kubernetes/commit/%H' | \
-  grep -v 'Merge pull request' | \
-  sed 's#,UPSTREAM: \([0-9]*\)\(:.*\)#,UPSTREAM: \1\2,https://github.com/kubernetes/kubernetes/pull/\1#' > \
-  v1.19.2.csv
+echo 'Comment Sha\tAction\tClean\tSummary\tCommit link\tPR link' > ~/Documents/v1.19.2.tsv
+```
+```
+git log $( git merge-base openshift/master v1.19.2 )..openshift/master --ancestry-path --reverse --no-merges --pretty='tformat:%x09%h%x09%x09%x09%s%x09https://github.com/openshift/kubernetes/commit/%h?w=1' | grep -E $'\t''UPSTREAM: .*'$'\t' | sed -E 's~UPSTREAM: ([0-9]+)(:.*)~UPSTREAM: \1\2\thttps://github.com/kubernetes/kubernetes/pull/\1~' >> ~/Documents/v1.19.2.tsv
 ```
 
-This csv file can be imported into a google sheets spreadsheet to track the
+This tsv file can be imported into a google sheets spreadsheet to track the
 progress of picking commits to the new rebase branch. The spreadsheet can also
 be a way of communicating with rebase reviewers. For an example of this
 communication, please see the [the spreadsheet used for the 1.19
 rebase](https://docs.google.com/spreadsheets/d/10KYptJkDB1z8_RYCQVBYDjdTlRfyoXILMa0Fg8tnNlY/edit).
 
 ## Picking commits from the previous rebase branch to the new branch
+Go through the spreadsheet and for every commit set one of the appropriate actions:
+ - `p`, to pick the commit
+ - `s`, to squash it (add a comment with the sha of the target)
+ - `d`, to drop the commit (if it is not obvious, comment why)
+
+Set up conditional formatting in the google sheet to color these lines appropriately. 
 
 Commits carried on rebase branches have commit messages prefixed as follows:
 
@@ -102,27 +110,36 @@ Commits carried on rebase branches have commit messages prefixed as follows:
     - <img src="openshift-hack/commit-tag.png">
 
 With these guidelines in mind, pick the appropriate commits from the previous rebase
-branch into the new rebase branch. As per the example of previous rebase spreadsheets,
-color each commit in the spreadsheet to indicate to reviewers whether or not a commit
-was picked and the rationale for your choice.
+branch into the new rebase branch. Create a new filter view in the spreadsheet to allow
+you get a view where `Action==p || Action==s` and copy paste the shas to `git cherry-pick`
+command. Use `tr '\n' ' ' <<< "<line_separated_commits>"` to get a space separated list
+from the copy&paste.
 
 Where it makes sense to do so, squash carried changes that are tightly coupled to
 simplify future rebases. If the commit message of a carry does not conform to
 expectations, feel free to revise and note the change in the spreadsheet row for the
 commit.
 
+If you first pick all the pick+squash commits first and push them for review it is easier for you
+and your reviewers to check the code changes and you squash it at the end. 
+
+Explicit commit rules:
+- Anything touching `openshift-hack/`, openshift specific READMEs or similar files
+  should be squashed to 1 commit named "UPSTREAM: <carry>: Add OpenShift specific files"
+- Updating generated files coming from kubernetes should be `<drop>` commit 
+
 ## Update the hyperkube image version to the release tag
 
 The [hyperkube dockerfile](openshift-hack/images/hyperkube/Dockerfile.rhel)
 hard-codes the Kubernetes version in an image label. It's necessary to manually
 set this label to the new release tag. Prefix the commit summary with
-`UPSTREAM: <drop>:` since a future rebase will need to add its own commit.
+`UPSTREAM: <carry>: (squash)` and squash it before merging the rebase PR.
 
 ## Updating dependencies
 
-Once the commits are all picked from the previous rebase branch, each of the
-following repositories need to be updated to depend on the upstream tag
-targeted by the rebase:
+Once the commits are all picked from the previous rebase branch, and your PR
+is mostly ready, each of the following repositories need to be updated to depend
+on the upstream tag targeted by the rebase:
 
 - https://github.com/openshift/api
 - https://github.com/openshift/apiserver-library-go
@@ -132,26 +149,29 @@ targeted by the rebase:
 Often these repositories are updated in parallel by other team members, so make
 sure to ask around before starting the work of bumping their dependencies.
 
-Once the above repos have been updated to the target release, it will be necessary to
-update go.mod to point to the appropriate revision of these repos by running
-`hack/pin-dependency.sh` for each of them and then running `hack/update-vendor.sh` (as
-per the [upstream
-documentation](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/vendor.md#adding-or-updating-a-dependency)).
+Once the above repos have been updated to depend on the target release, 
+it will be necessary to update `go.mod` to point to the appropriate revision
+of these repos by running `hack/pin-dependency.sh` for each of them and then running
+`hack/update-vendor.sh` (as per the [upstream documentation](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/vendor.md#adding-or-updating-a-dependency)).
 
 Make sure to commit the result of a vendoring update with `UPSTREAM: <drop>: bump(*)`.
+If you have already bumped the dependencies to get the repo to compile,
+don't forget to squash the commits before merging the PR.
 
 ### Updating dependencies for pending bumps
 
 The upstream `hack/pin-dependency.sh` script only supports setting dependency
 for the original repository. To pin to a fork branch that has not yet been
 merged (i.e. to test a rebase ahead of shared library bumps having merged), the
-following `go mod` invovations are suggested:
+following `go mod` invocations are suggested:
 
 ```
 go mod edit -replace github.com/openshift/<lib>=github.com/<username>/<lib>@SHA
-go mod tidy
+go mod tidy && go mod vendor
 ```
 
+Alternatively, you can edit `go.mod` file manually with your favourite editor and use search&replace.
+
 ## Review test annotation rules
 
 The names of upstream e2e tests are annotated according to the a set of
@@ -178,17 +198,22 @@ regression in behavior) can often be skipped and addressed post-merge.
 - Update generated files by running `make update`
   - This step depends on etcd being installed in the path, which can be
     accomplished by running `hack/install-etcd.sh`.
+  - Alternatively, run it in the same container as CI is using for build_root that already has 
+    the etcd at correct version
+```
+podman run -it --rm -v $( pwd ):/go/k8s.io/kubernetes:Z --workdir=/go/k8s.io/kubernetes registry.svc.ci.openshift.org/openshift/release:rhel-8-release-golang-1.15-openshift-4.7 make update OS_RUN_WITHOUT_DOCKER=yes
+```
 - Commit the resulting changes as `UPSTREAM: <drop>: make update`.
 
 ## Building and testing
 
 - Build the code with `make`
 - Test the code with `make test`
   - Where test failures are encountered and can't be trivially resolved, the
-    spreadsheet can be used to to track those failures to their resolution. The
+    spreadsheet can be used to track those failures to their resolution. The
     example spreadsheet should have a sheet that demonstrates this tracking.
   - Where a test failure proves challenging to fix without specialized knowledge,
-    make sure to coordinate with the team(s) responsible for areas of focus
+    make sure to coordinate with the team(s) responsible for area(s) of focus
     exhibiting test failure. If in doubt, ask for help!
 - Verify the code with `make verify`
 
@@ -206,36 +231,24 @@ should be true:
 - [ ] `make` executes without error
 - [ ] `make verify` executes without error
 - [ ] `make test` executes without error
-- [ ] Upstream tags are pushed to `openshift/kubernetes` to ensure that
+- [ ] The upstream tag is pushed to `openshift/kubernetes` to ensure that
       build artifacts are versioned correctly
       - Upstream tooling uses the value of the most recent tag (e.g. `v1.20.0`)
         in the branch history as the version of the binaries it builds.
+      - Pushing the tag is easy as
+```
+git push [email protected]:openshift/kubernetes.git refs/tags/v1.20.0
+```
 
 Details to include in the description of the PR:
 
 - [ ] A link to the rebase spreadsheet for the benefit for reviewers
-- [ ] A comment reminding reviewers of the need for manual upgrade testing
-      along with a `/hold` command to prevent merge until such testing is
-      completed.
-
-In addition to the standard requirement that all CI jobs be passing, the rebase
-PR should not be merged until additional upgrade testing initiated with
-cluster-bot is passing:
-
-- [ ] `test upgrade [previous release e.g. 4.6] openshift/kubernetes#[PR#] [aws|azure]`
-       - Only gcp upgrades are tested automatically via presubmit
-         (`e2e-gcp-upgrade`) and it's necessary to manually test aws and azure.
-- [ ] `test upgrade openshift/kubernetes#[PR#] openshift/kubernetes#[PR#]`
-      - This 'self-upgrade' ensures that it is possible to upgrade _from_ the
-        rebased release. The other upgrade testing validates that it's possible
-        to upgrade _to_ the rebased release.
 
 After the rebase PR has merged to `openshift/kubernetes`, vendor the changes
-into `origin` to ensure that the openshift-tests binary reflects the upstream
-test changes introduced by the rebase:
+into `openshift/origin` to ensure that the openshift-tests binary reflects 
+the upstream test changes introduced by the rebase:
 
-- [ ] Find the SHA of `openshift/kubernetes` branch after merge of the rebase
-      PR
+- [ ] Find the SHA of the merge commit after your PR lands in `openshift/kubernetes`
 - [ ] Run `hack/update-kube-vendor.sh <o/k SHA>` in a clone of the `origin`
       repo and commit the results
 - [ ] Run `make update` and commit the results
@@ -247,5 +260,5 @@ rebase. Make sure to include:
 - [ ] The new version of upstream Kubernetes that OpenShift is now based on
 - [ ] Link(s) to upstream changelog(s) detailing what has changed since the last rebase landed
 - [ ] A reminder to component maintainers to bump their dependencies
-- [ ] Relevent details of the challenges involved in landing the rebase that
+- [ ] Relevant details of the challenges involved in landing the rebase that
       could benefit from a wider audience.

api/OWNERS

@@ -2,7 +2,7 @@
 
 # Disable inheritance as this is an api owners file
 options:
-  no_parent_owners: true
+  no_parent_owners: false
 approvers:
 - api-approvers
 reviewers:

build/common.sh

@@ -93,8 +93,6 @@ readonly KUBE_CONTAINER_RSYNC_PORT=8730
 #
 # $1 - server architecture
 kube::build::get_docker_wrapped_binaries() {
-  local arch=$1
-  local debian_base_version=v2.1.3
   local debian_iptables_version=v12.1.2
   local go_runner_version=buster-v2.0.0
   ### If you change any of these lists, please also update DOCKERIZED_BINARIES
@@ -103,7 +101,7 @@ kube::build::get_docker_wrapped_binaries() {
     "kube-apiserver,${KUBE_BASE_IMAGE_REGISTRY}/go-runner:${go_runner_version}"
     "kube-controller-manager,${KUBE_BASE_IMAGE_REGISTRY}/go-runner:${go_runner_version}"
     "kube-scheduler,${KUBE_BASE_IMAGE_REGISTRY}/go-runner:${go_runner_version}"
-    "kube-proxy,${KUBE_BASE_IMAGE_REGISTRY}/debian-iptables-${arch}:${debian_iptables_version}"
+    "kube-proxy,${KUBE_BASE_IMAGE_REGISTRY}/debian-iptables:${debian_iptables_version}"
   )
 
   echo "${targets[@]}"

build/dependencies.yaml

@@ -26,7 +26,7 @@ dependencies:
 
   # CNI plugins
   - name: "cni"
-    version: 0.8.6
+    version: 0.8.7
     refPaths:
     - path: build/workspace.bzl
       match: CNI_VERSION =
@@ -74,7 +74,7 @@ dependencies:
 
   # etcd
   - name: "etcd"
-    version: 3.4.9
+    version: 3.4.13
     refPaths:
     - path: cluster/gce/manifests/etcd.manifest
       match: etcd_docker_tag|etcd_version
@@ -118,8 +118,6 @@ dependencies:
   - name: "k8s.gcr.io/debian-base: dependents"
     version: 2.1.3
     refPaths:
-    - path: build/common.sh
-      match: debian_base_version=
     - path: build/workspace.bzl
       match: tag =
     - path: cluster/images/etcd/Makefile

build/lib/release.sh

@@ -334,7 +334,7 @@ function kube::release::create_docker_images_for_server() {
     local images_dir
     binary_dir="$1"
     arch="$2"
-    binaries=$(kube::build::get_docker_wrapped_binaries "${arch}")
+    binaries=$(kube::build::get_docker_wrapped_binaries)
     images_dir="${RELEASE_IMAGES}/${arch}"
     mkdir -p "${images_dir}"
 
@@ -375,7 +375,7 @@ function kube::release::create_docker_images_for_server() {
         ln "${KUBE_ROOT}/build/nsswitch.conf" "${docker_build_path}/nsswitch.conf"
         chmod 0644 "${docker_build_path}/nsswitch.conf"
         cat <<EOF > "${docker_file_path}"
-FROM ${base_image}
+FROM --platform=linux/${arch} ${base_image}
 COPY ${binary_name} /usr/local/bin/${binary_name}
 EOF
         # ensure /etc/nsswitch.conf exists so go's resolver respects /etc/hosts

build/workspace.bzl

@@ -17,13 +17,13 @@ load("//build:workspace_mirror.bzl", "mirror")
 load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive", "http_file")
 load("@io_bazel_rules_docker//container:container.bzl", "container_pull")
 
-CNI_VERSION = "0.8.6"
+CNI_VERSION = "0.8.7"
 _CNI_TARBALL_ARCH_SHA256 = {
-    "amd64": "994fbfcdbb2eedcfa87e48d8edb9bb365f4e2747a7e47658482556c12fd9b2f5",
-    "arm": "28e61b5847265135dc1ca397bf94322ecce4acab5c79cc7d360ca3f6a655bdb7",
-    "arm64": "43fbf750c5eccb10accffeeb092693c32b236fb25d919cf058c91a677822c999",
-    "ppc64le": "61d6c6c15d3e4fa3eb85d128c9c0ff2658f38e59047ae359be47d193c673e116",
-    "s390x": "ca126a3bd2cd8dff1c7bbfc3c69933b284c4e77614391c7e1f74b0851fc3b289",
+    "amd64": "977824932d5667c7a37aa6a3cbba40100a6873e7bd97e83e8be837e3e7afd0a8",
+    "arm": "5757778f4c322ffd93d7586c60037b81a2eb79271af6f4edf9ff62b4f7868ed9",
+    "arm64": "ae13d7b5c05bd180ea9b5b68f44bdaa7bfb41034a2ef1d68fd8e1259797d642f",
+    "ppc64le": "70a8c5448ed03a3b27c6a89499a05285760a45252ec7eae4190c70ba5400d4ba",
+    "s390x": "3a0008f98ea5b4b6fd367cac3d8096f19bc080a779cf81fd0bcbc5bd1396ace7",
 }
 
 CRI_TOOLS_VERSION = "1.18.0"
@@ -38,11 +38,11 @@ _CRI_TARBALL_ARCH_SHA256 = {
     "windows-amd64": "5045bcc6d8b0e6004be123ab99ea06e5b1b2ae1e586c968fcdf85fccd4d67ae1",
 }
 
-ETCD_VERSION = "3.4.9"
+ETCD_VERSION = "3.4.13"
 _ETCD_TARBALL_ARCH_SHA256 = {
-    "amd64": "bcab421f6bf4111accfceb004e0a0ac2bcfb92ac93081d9429e313248dd78c41",
-    "arm64": "fd9bf37662a851905d75160fea0f5d10055c1bee0a734e78c5112cc56c9faa18",
-    "ppc64le": "bfdcea0fc83c6d6edb70667a2272f8fc597c61976ecc6f8ecbfeb380ff02618b",
+    "amd64": "2ac029e47bab752dacdb7b30032f230f49e2f457cbc32e8f555c2210bb5ff107",
+    "arm64": "1934ebb9f9f6501f706111b78e5e321a7ff8d7792d3d96a76e2d01874e42a300",
+    "ppc64le": "fc77c3949b5178373734c3b276eb2281c954c3cd2225ccb05cdbdf721e1f775a",
 }
 
 # Dependencies needed for a Kubernetes "release", e.g. building docker images,

cluster/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml

@@ -105,6 +105,4 @@ spec:
       tolerations:
       - key: "CriticalAddonsOnly"
         operator: "Exists"
-      nodeSelector:
-        kubernetes.io/os: linux
       serviceAccountName: kube-dns-autoscaler

cluster/addons/volumesnapshots/volume-snapshot-controller/volume-snapshot-controller-deployment.yaml

@@ -22,8 +22,6 @@ spec:
       serviceAccount: volume-snapshot-controller
       containers:
         - name: volume-snapshot-controller
-          # TODO(xyang): Replace with an official image when it is released
-          image: gcr.io/k8s-staging-csi/snapshot-controller:v2.0.0-rc2
+          image: k8s.gcr.io/sig-storage/snapshot-controller:v2.1.1
           args:
             - "--v=5"
-          imagePullPolicy: Always

cluster/gce/config-common.sh

@@ -142,7 +142,7 @@ export WINDOWS_CNI_CONFIG_DIR="${WINDOWS_K8S_DIR}\cni\config"
 # CNI storage path for Windows nodes
 export WINDOWS_CNI_STORAGE_PATH="https://storage.googleapis.com/k8s-artifacts-cni/release"
 # CNI version for Windows nodes
-export WINDOWS_CNI_VERSION="v0.8.6"
+export WINDOWS_CNI_VERSION="v0.8.7"
 # Pod manifests directory for Windows nodes on Windows nodes.
 export WINDOWS_MANIFESTS_DIR="${WINDOWS_K8S_DIR}\manifests"
 # Directory where cert/key files will be stores on Windows nodes.

cluster/gce/config-test.sh

@@ -202,7 +202,7 @@ HEAPSTER_MACHINE_TYPE=${HEAPSTER_MACHINE_TYPE:-}
 NUM_ADDITIONAL_NODES=${NUM_ADDITIONAL_NODES:-}
 ADDITIONAL_MACHINE_TYPE=${ADDITIONAL_MACHINE_TYPE:-}
 
-# Set etcd image (e.g. k8s.gcr.io/etcd) and version (e.g. 3.4.9-1) if you need
+# Set etcd image (e.g. k8s.gcr.io/etcd) and version (e.g. 3.4.13-0) if you need
 # non-default version.
 export ETCD_IMAGE=${TEST_ETCD_IMAGE:-}
 export ETCD_DOCKER_REPOSITORY=${TEST_ETCD_DOCKER_REPOSITORY:-}