Static manifest generation uses kustomize instead of python (kubernet…

…es#8099) * regenerate at 4.0.12 * bash for loop and static values files * add .tool-versions * fixup static manifests with kustomize instead of python * remove spec.replicas where set * generate manifests for all supported versions * update docs * remove all versions except default (1.20) for now * update to 1.1.1/4.0.15
jp · Jan 17, 2022 · d16e0de · d16e0de
1 parent a665a40
commit d16e0de
Show file tree

Hide file tree

Showing 32 changed files with 4,300 additions and 4,456 deletions.
diff --git a/RELEASE.md b/RELEASE.md
@@ -1,14 +1,14 @@
 # RELEASE PROCESS
 
-## 1. BUILD the new Ingress-Nginx-Controller image 
+## 1. BUILD the new Ingress-Nginx-Controller image
 
 ### a. Make changes in codebase
 
 - Make changes as per issue
 
 ### b. Make changes to appropriate files in [images directory ](images)
 
-- Make changes in /images 
+- Make changes in /images
 
 ### c. Create Pull Request
 
@@ -18,15 +18,15 @@
 
   - Example [NGINX_VERSION](images/nginx/rootfs/build.sh#L21), [SHA256](images/nginx/rootfs/build.sh#L124).
 
-  - If you are updating any component in [build.sh](images/nginx/rootfs/build.sh) please also update the SHA256 checksum of that component as well, the cloud build will fail with an exit 10 if not.  
+  - If you are updating any component in [build.sh](images/nginx/rootfs/build.sh) please also update the SHA256 checksum of that component as well, the cloud build will fail with an exit 10 if not.
 
 ### d. Merge
 
 - Merging will fire cloudbuild, which will result in images being promoted to the [staging container registry](https://console.cloud.google.com/gcr/images/k8s-staging-ingress-nginx).
 
 ### e. Make sure cloudbuild is a success
 
-- Wait for [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx). If you don't have access to cloudbuild, you can also have a look at [this](https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*), to see the progress of the build. 
+- Wait for [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx). If you don't have access to cloudbuild, you can also have a look at [this](https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*), to see the progress of the build.
 
 - Proceed only after cloud-build is successful in building a new Ingress-Nginx-Controller image.
 
@@ -42,7 +42,7 @@
 ### b. Make changes to appropriate files in [images directory ](images)
 
 - Sometimes, you may also be needing to rebuild, images for one or multiple other related components of the Ingress-Nginx-Controller ecosystem. Make changes to the required files in the /images directory, if/as applicable, in the context of the release you are attempting.  :
-   
+
   - [e2e](https://github.com/kubernetes/ingress-nginx/tree/main/test/e2e-image)
 
     - Update references to e2e-test-runner image [If applicable] :
@@ -72,24 +72,24 @@
 
 ### e. Make sure cloudbuild is a success
 
-- Wait for [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx). If you don't have access to cloudbuild, you can also have a look at [this](https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*), to see the progress of the build. 
+- Wait for [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx). If you don't have access to cloudbuild, you can also have a look at [this](https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*), to see the progress of the build.
 
 - Proceed only after cloud-build is successful in building a new Ingress-Nginx-Controller image.
 
 
 ## 3. PROMOTE the Image(s):
 
-Promoting the images basically means that images, that were pushed to staging container registry in the steps above, now are also pushed to the public container registry. Thus are publicly available. Follow these steps to promote images: 
+Promoting the images basically means that images, that were pushed to staging container registry in the steps above, now are also pushed to the public container registry. Thus are publicly available. Follow these steps to promote images:
 
 ### a. Get the sha
 
-- Get the sha of the new image(s) of the controller, (and any other component image IF APPLICABLE to release), from the cloudbuild, from steps above 
+- Get the sha of the new image(s) of the controller, (and any other component image IF APPLICABLE to release), from the cloudbuild, from steps above
 
   - The sha is available in output from [cloud build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-ingress-nginx)
 
   - The sha is also visible here https://console.cloud.google.com/gcr/images/k8s-staging-ingress-nginx/global/controller
 
-  - The sha is also visible [here]((https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*)), after cloud build is finished. Click on the respective job, go to `Artifacts` section in the UI, then again `artifacts` in the directory browser. In the `build.log` at the very bottom you see something like this: 
+  - The sha is also visible [here]((https://prow.k8s.io/?repo=kubernetes%2Fingress-nginx&job=post-*)), after cloud build is finished. Click on the respective job, go to `Artifacts` section in the UI, then again `artifacts` in the directory browser. In the `build.log` at the very bottom you see something like this:
 
   ```
   ...
@@ -99,7 +99,7 @@ Promoting the images basically means that images, that were pushed to staging co
 
 ### b. Add the new image to [k8s.io](http://github.com/kubernetes/k8s.io)
 
-- The sha(s) from the step before (and the tag(s) for the new image(s) have to be added, as a new line, in a file, of the [k8s.io](http://github.com/kubernetes/k8s.io) project of Kubernetes organization. 
+- The sha(s) from the step before (and the tag(s) for the new image(s) have to be added, as a new line, in a file, of the [k8s.io](http://github.com/kubernetes/k8s.io) project of Kubernetes organization.
 
 - Fork that other project (if you don't have a fork already).
 
@@ -113,7 +113,7 @@ Promoting the images basically means that images, that were pushed to staging co
 
 - For making it easier, you can edit your branch directly in the browser. But be careful about making any mistake.
 
-- Insert the sha(s) & the tag(s), in a new line, in this file [Project kubernetes/k8s.io Ingress-Nginx-Controller Images](https://github.com/kubernetes/k8s.io/blob/main/k8s.gcr.io/images/k8s-staging-ingress-nginx/images.yaml)  Look at this [example PR and the diff](https://github.com/kubernetes/k8s.io/pull/2536) to see how it was done before 
+- Insert the sha(s) & the tag(s), in a new line, in this file [Project kubernetes/k8s.io Ingress-Nginx-Controller Images](https://github.com/kubernetes/k8s.io/blob/main/k8s.gcr.io/images/k8s-staging-ingress-nginx/images.yaml)  Look at this [example PR and the diff](https://github.com/kubernetes/k8s.io/pull/2536) to see how it was done before
 
 - Save and commit
 
@@ -130,13 +130,13 @@ Promoting the images basically means that images, that were pushed to staging co
 
 ## 4. PREPARE for a new Release
 
-- Make sure to get the tag and sha of the promoted image from the step before, either from cloudbuild or from [here](https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/ingress-nginx/controller). 
+- Make sure to get the tag and sha of the promoted image from the step before, either from cloudbuild or from [here](https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/ingress-nginx/controller).
 
 - This involves editing of several different files. So carefully follow the steps below and double check all changes with diff/grep etc., repeatedly. Mistakes here impact endusers.
 
 ### a. Make sure your git workspace is ready
 
-- Get your git workspace ready 
+- Get your git workspace ready
 
   - If not using a pre-existing fork, then Fork the repo kubernetes/ingress-nginx
 
@@ -165,7 +165,7 @@ Promoting the images basically means that images, that were pushed to staging co
     - appVersion
     - kubeVersion (**ONLY if applicable**)
     - annotations
-      - artifacthub.io/prerelease: "true" 
+      - artifacthub.io/prerelease: "true"
       - artifacthub.io/changes: |
         - Replace this line and other lines under this annotation with the Changelog. One process to generate the Changelog is described below
           - Install and configure github cli as per the docs of gh-cli  https://cli.github.com/,
@@ -230,41 +230,21 @@ Promoting the images basically means that images, that were pushed to staging co
 
   - Prepare to use a script to update the edit the static manifests and set the "image", "digest", "version" etc. fields to the desired value.
 
+  - This script depends on kustomize and helm. The versions are pinned in `hack/.tool-versions` and you can use [asdf](https://github.com/asdf-vm/asdf#asdf) to install them
 
-  - This script depends on python and a specific python package `pip3 install ruamel.yaml`
+  - Execute the script to update static manifests using that script [hack/generate-deploy-scripts.sh](https://github.com/kubernetes/ingress-nginx/blob/main/hack/generate-deploy-scripts.sh)
 
-  - Execute the script to update static manifests using that script [generate-deploy-scripts.sh](https://github.com/kubernetes/ingress-nginx/blob/main/hack/generate-deploy-scripts.sh)
   - Open some of the manifests and check if the script worked properly
 
   - Use grep -ir to search for any misses by the script or undesired changes
 
   - The script should properly set the image and the digest fields to the desired tag and semver
 
-  - Manually fix one problem that the script can not take care of.
-
-    - This problem is wrong formatting of a snippet in the file [deploy-tls-termination.yaml](https://github.com/kubernetes/ingress-nginx/blob/main/deploy/static/provider/aws/deploy-tls-termination.yaml)
-    - In the configMap section, for the configMap named ingress-nginx-controller, the "configMap.data" spec has a snippet
-
-    - This snippet becomes a single line, formatted with the newline character "\n"
-
-    - That single line formatted with "\n" needs to be changed as it does not meet yaml requirements
 
-    - At the time of writing this doc, the 'configMap.data' spec is at line number 39.
-
-    - So editing begins at line 40 (at the time of writing this doc)
-
-    - Make that snippet look like this ;
-      ```
-      data:
-        http-snippet:|
-          server{
-            listen 2443;
-            return 308 https://$host$request_uri;
-          }
-      ```
 
 ### f. Edit the changelog
-  [Changelog.md](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md) 
+
+  [Changelog.md](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md)
 - Each time a release is made, a new section is added to the Changelog.md file
 - A new section in the Changelog.md file consists of 3 components listed below
   - the "Image"
@@ -277,8 +257,9 @@ Promoting the images basically means that images, that were pushed to staging co
 - One process to generate this list of PRs is already described above in step 4c. So if you are following this document, then you have done this already and very likely have retained the file containing the list of PRs, in the format that is needed.
 
 ### g. Edit the Documentation:
+
 - Update the version in [docs/deploy/index.md](docs/deploy/index.md)
-- Update Supported versions in the Support Versions table in the README.md 
+- Update Supported versions in the Support Versions table in the README.md
 
 ### h. Edit stable.txt
 
@@ -294,7 +275,7 @@ Promoting the images basically means that images, that were pushed to staging co
 
 - Open PR for releasing the new version of the Ingress-Nginx-Controller ;
   - Look at this PR for how it was done before [example PR](https://github.com/kubernetes/ingress-nginx/pull/7490)
-  - Create a PR 
+  - Create a PR
 
 ### b. Merge