Release 1.4.2 (#115)

Author: lucacome

CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+### 1.4.2
+
+An automatically generated list of changes can be found on Github at: [1.4.2 Release](https://github.com/nginxinc/nginx-ingress-helm-operator/releases/tag/v1.4.2)
+
 ### 1.4.1
 
 An automatically generated list of changes can be found on Github at: [1.4.1 Release](https://github.com/nginxinc/nginx-ingress-helm-operator/releases/tag/v1.4.1)

Makefile

@@ -3,7 +3,7 @@
 # To re-generate a bundle for another specific version without changing the standard setup, you can:
 # - use the VERSION as arg of the bundle target (e.g make bundle VERSION=0.0.2)
 # - use environment variables to overwrite this value (e.g export VERSION=0.0.2)
-VERSION ?= 1.4.1
+VERSION ?= 1.4.2
 
 # CHANNELS define the bundle channels used in the bundle.
 # Add a new line here if you would like to change its default config. (E.g CHANNELS = "candidate,fast,stable")

README.md

@@ -13,8 +13,8 @@ Up until version 0.5.1, this Operator was Go based. Version 1.0.0 marks an incom
 The following table shows the relation between the versions of the two projects:
 
 | NGINX Ingress Controller | NGINX Ingress Operator |
-|--------------------------|------------------------|
-| 3.1.x                    | 1.4.1                  |
+| ------------------------ | ---------------------- |
+| 3.1.x                    | 1.4.2                  |
 | 3.0.x                    | 1.3.1                  |
 | 2.4.x                    | 1.2.1                  |
 | 2.3.x                    | 1.1.0                  |
@@ -34,37 +34,40 @@ Note: The NGINX Ingress Operator works only for NGINX Ingress Controller version
 ## Getting Started
 
 1. Install the NGINX Ingress Operator. See [docs](./docs/installation.md).
-   <br> NOTE: To use TransportServers as part of your NGINX Ingress Controller configuration, a GlobalConfiguration resource must be created *before* starting the Operator - [see the notes](./examples/deployment-oss-min/README.md#TransportServers)
+   <br> NOTE: To use TransportServers as part of your NGINX Ingress Controller configuration, a GlobalConfiguration resource must be created _before_ starting the Operator - [see the notes](./examples/deployment-oss-min/README.md#TransportServers)
 2. Creating the default-server-secret.yaml is optional and it is recommended that users provide their own certificate. An example yaml for this can be found in the [examples folder](https://github.com/nginxinc/nginx-ingress-helm-operator/blob/main/examples/default-server-secret.yaml)
 3. (If using OpenShift) Create the scc resource on the cluster by applying the scc.yaml file found in the `resources` folder of this repo:
-  ```shell
-  kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/main/resources/scc.yaml
-  ```
-4. Deploy a new NGINX Ingress Controller using the [NginxIngress](./config/samples/charts_v1alpha1_nginxingress.yaml) Custom Resource:
-    * Use the name of the default server secret created above for `controller.defaultTLS.secret` field (needs to be in the form `namespace/name`)
-    * If using NGINX Plus:
-      * Set the `controller.nginxPlus` to true
-      * Set the `controller.image.repository` and `controller.image.tag` to the appropriate values
-      * Set the `controller.serviceAccount.imagePullSecretName` if applicable
-    * For full configuration details see the Helm documentation [here](https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-helm/#configuration).
 
+```shell
+kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/main/resources/scc.yaml
+```
+
+4. Deploy a new NGINX Ingress Controller using the [NginxIngress](./config/samples/charts_v1alpha1_nginxingress.yaml) Custom Resource:
+   - Use the name of the default server secret created above for `controller.defaultTLS.secret` field (needs to be in the form `namespace/name`)
+   - If using NGINX Plus:
+     - Set the `controller.nginxPlus` to true
+     - Set the `controller.image.repository` and `controller.image.tag` to the appropriate values
+     - Set the `controller.serviceAccount.imagePullSecretName` if applicable
+   - For full configuration details see the Helm documentation [here](https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-helm/#configuration).
 
 ## Notes: Multiple NIC Deployments
-* Please see [the NGINX Ingress Controller documentation](https://docs.nginx.com/nginx-ingress-controller/installation/running-multiple-ingress-controllers/) for general information on running multiple NGINX Ingress Controllers in your cluster.
-* To run multiple NIC instances deployed by the NGINX Ingress Operator in your cluster in the same namespace, `rbac.create` should be set to `false`, and the ServiceAccount and ClusterRoleBinding need to be created independently of the deployments. Please note that `controller.serviceAccount.imagePullSecretName` will also be ignored in this configuration, and will need to be configured as part of the independent ServiceAccount creation.
-* The ClusterRoleBinding needs to configured to bind to the `nginx-ingress-operator-nginx-ingress-admin` ClusterRole.
-* See [RBAC example spec](../resources/rbac-example.yaml) for an example ServiceAccount and ClusterRoleBinding manifest.
-* To run multiple NIC instances deployed by the NGINX Ingress Operator in your cluster in any namespace but sharing an IngressClass, `controller.ingressClass` should be set to an empty string and the IngressClass resource needs to be created independently of the deployments.Please note that `controller.setAsDefaultIngress` will also be ignored in this configuration, and will need to be configured as part of the independent IngressClass creation.
-* See [IngressClass example spec](../resources/ingress-class.yaml) for an example IngressClass manifest.
+
+- Please see [the NGINX Ingress Controller documentation](https://docs.nginx.com/nginx-ingress-controller/installation/running-multiple-ingress-controllers/) for general information on running multiple NGINX Ingress Controllers in your cluster.
+- To run multiple NIC instances deployed by the NGINX Ingress Operator in your cluster in the same namespace, `rbac.create` should be set to `false`, and the ServiceAccount and ClusterRoleBinding need to be created independently of the deployments. Please note that `controller.serviceAccount.imagePullSecretName` will also be ignored in this configuration, and will need to be configured as part of the independent ServiceAccount creation.
+- The ClusterRoleBinding needs to configured to bind to the `nginx-ingress-operator-nginx-ingress-admin` ClusterRole.
+- See [RBAC example spec](../resources/rbac-example.yaml) for an example ServiceAccount and ClusterRoleBinding manifest.
+- To run multiple NIC instances deployed by the NGINX Ingress Operator in your cluster in any namespace but sharing an IngressClass, `controller.ingressClass` should be set to an empty string and the IngressClass resource needs to be created independently of the deployments.Please note that `controller.setAsDefaultIngress` will also be ignored in this configuration, and will need to be configured as part of the independent IngressClass creation.
+- See [IngressClass example spec](../resources/ingress-class.yaml) for an example IngressClass manifest.
 
 ## Upgrades
 
 See [upgrade docs](./docs/upgrades.md)
 
 ## NGINX Ingress Operator Releases
+
 We publish NGINX Ingress Operator releases on GitHub. See our [releases page](https://github.com/nginxinc/nginx-ingress-helm-operator/releases).
 
-The latest stable release is [1.4.1](https://github.com/nginxinc/nginx-ingress-helm-operator/releases/tag/v1.4.1). For production use, we recommend that you choose the latest stable release.
+The latest stable release is [1.4.2](https://github.com/nginxinc/nginx-ingress-helm-operator/releases/tag/v1.4.2). For production use, we recommend that you choose the latest stable release.
 
 ## Development
 
@@ -73,11 +76,11 @@ It is possible to run the operator in your local machine. This is useful for tes
 ### Run Operator locally
 
 1. Have access to a Kubernetes/OpenShift cluster.
-1. Apply the IC CRD:
+2. Apply the IC CRD:
    ```
     make install
-    ```
-2. Run `make run`.
+   ```
+3. Run `make run`.
 
 The operator will run in your local machine but will be communicating with the cluster.
 

bundle/manifests/nginx-ingress-operator.clusterserviceversion.yaml

@@ -176,8 +176,8 @@ metadata:
     capabilities: Basic Install
     categories: Monitoring, Networking
     certified: "true"
-    containerImage: quay.io/nginx/nginx-ingress-operator:1.4.1
-    createdAt: "2023-05-18T04:36:32Z"
+    containerImage: quay.io/nginx/nginx-ingress-operator:1.4.2
+    createdAt: "2023-05-25T21:05:22Z"
     description: The NGINX Ingress Operator is a Kubernetes/OpenShift component which
       deploys and manages one or more NGINX/NGINX Plus Ingress Controllers
     operatorframework.io/suggested-namespace: nginx-ingress
@@ -190,7 +190,7 @@ metadata:
     operatorframework.io/arch.arm64: supported
     operatorframework.io/arch.ppc64le: supported
     operatorframework.io/arch.s390x: supported
-  name: nginx-ingress-operator.v1.4.1
+  name: nginx-ingress-operator.v1.4.2
   namespace: placeholder
 spec:
   apiservicedefinitions: {}
@@ -394,7 +394,7 @@ spec:
                 - --metrics-bind-address=127.0.0.1:8080
                 - --leader-elect
                 - --leader-election-id=nginx-ingress-operator
-                image: nginx/nginx-ingress-operator:1.4.1
+                image: nginx/nginx-ingress-operator:1.4.2
                 livenessProbe:
                   httpGet:
                     path: /healthz
@@ -485,4 +485,4 @@ spec:
   minKubeVersion: 1.21.0
   provider:
     name: NGINX Inc
-  version: 1.4.1
+  version: 1.4.2

config/manager/kustomization.yaml

@@ -5,4 +5,4 @@ kind: Kustomization
 images:
 - name: controller
   newName: nginx/nginx-ingress-operator
-  newTag: 1.4.1
+  newTag: 1.4.2

config/manifests/bases/nginx-ingress-operator.clusterserviceversion.yaml

@@ -176,7 +176,7 @@ metadata:
     capabilities: Basic Install
     categories: Monitoring, Networking
     certified: "true"
-    containerImage: quay.io/nginx/nginx-ingress-operator:1.4.1
+    containerImage: quay.io/nginx/nginx-ingress-operator:1.4.2
     createdAt: placeholder
     description: The NGINX Ingress Operator is a Kubernetes/OpenShift component which
       deploys and manages one or more NGINX/NGINX Plus Ingress Controllers
@@ -345,7 +345,7 @@ spec:
                 - --metrics-bind-address=127.0.0.1:8080
                 - --leader-elect
                 - --leader-election-id=nginx-ingress-operator
-                image: quay.io/nginx/nginx-ingress-operator:1.4.1
+                image: quay.io/nginx/nginx-ingress-operator:1.4.2
                 livenessProbe:
                   httpGet:
                     path: /healthz
@@ -451,4 +451,4 @@ spec:
   minKubeVersion: 1.21.0
   provider:
     name: NGINX Inc
-  version: 1.4.1
+  version: 1.4.2

docs/manual-installation.md

@@ -2,41 +2,44 @@
 
 This will deploy the operator in the `nginx-ingress-operator-system` namespace.
 
-
 1. Deploy the Operator and associated resources:
-   1. Clone the `nginx-ingress-operator` repo and checkout the latest stable tag:
-    ```
-    git clone https://github.com/nginxinc/nginx-ingress-helm-operator/
-    cd nginx-ingress-helm-operator/
-    git checkout v1.4.1
-    ```
+
+   1. Clone the `nginx-ingress-operator` repo:
+
+   ```
+   git clone https://github.com/nginxinc/nginx-ingress-helm-operator/ --branch v1.4.2
+   cd nginx-ingress-helm-operator/
+   ```
 
    2. `OpenShift` To deploy the Operator and associated resources to an OpenShift environment, run:
-    ```
-    make deploy IMG=nginx/nginx-ingress-operator:1.4.1
-    ```
+
+   ```
+   make deploy IMG=nginx/nginx-ingress-operator:1.4.2
+   ```
 
    3. Alternatively, to deploy the Operator and associated resources to all other environments:
-    ```
-    make deploy IMG=nginx/nginx-ingress-operator:1.4.1
-    ```
+
+   ```
+   make deploy IMG=nginx/nginx-ingress-operator:1.4.2
+   ```
 
 2. Check that the Operator is running:
-    ```
-    kubectl get deployments -n nginx-ingress-operator-system
 
-    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
-    nginx-ingress-operator-controller-manager   1/1     1            1           15s
-    ```
+   ```
+   kubectl get deployments -n nginx-ingress-operator-system
+
+   NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
+   nginx-ingress-operator-controller-manager   1/1     1            1           15s
+   ```
 
 3. `OpenShift` Additional steps:
 
 In order to deploy NGINX Ingress Controller instances into OpenShift environments, a new SCC is required to be created on the cluster which will be used to bind the specific required capabilities to the NGINX Ingress service account(s). To do so for NIC deployments, please run the following command (assuming you are logged in with administrator access to the cluster):
 
-`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.4.1/resources/scc.yaml`
+`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.4.2/resources/scc.yaml`
 
 Alternatively, to create an SCC for NIC daemonsets, please run this command:
 
-`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.4.1/resources/scc-daemonset.yaml`
+`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.4.2/resources/scc-daemonset.yaml`
 
-You can now deploy the NGINX Ingress Controller instances.
+You can now deploy the NGINX Ingress Controller instances.

docs/openshift-installation.md

@@ -7,11 +7,11 @@ This installation method is the recommended way for OpenShift users. **Note**: O
 The NGINX Ingress Operator is a [RedHat certified Operator](https://connect.redhat.com/en/partner-with-us/red-hat-openshift-operator-certification).
 
 1. In the OpenShift dashboard, click `Operators` > `Operator Hub` in the left menu and use the search box to type `nginx ingress`:
-![alt text](./images/openshift1.png "Operators")
+   ![alt text](./images/openshift1.png "Operators")
 1. Click the `NGINX Ingress Operator` and click `Install`:
-![alt text](./images/openshift2.png "NGINX Ingress Operator")
+   ![alt text](./images/openshift2.png "NGINX Ingress Operator")
 1. Click `Subscribe`:
-![alt text](./images/openshift3.png "NGINX Ingress Operator Install")
+   ![alt text](./images/openshift3.png "NGINX Ingress Operator Install")
 
 OpenShift will install the NGINX Ingress Operator:
 
@@ -21,10 +21,10 @@ Additional steps:
 
 In order to deploy NGINX Ingress Controller instances into OpenShift environments, a new SCC is required to be created on the cluster which will be used to bind the specific required capabilities to the NGINX Ingress service account(s). To do so for NIC deployments, please run the following command (assuming you are logged in with administrator access to the cluster):
 
-`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.4.1/resources/scc.yaml`
+`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.4.2/resources/scc.yaml`
 
 Alternatively, to create an SCC for NIC daemonsets, please run this command:
 
-`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.3.1/resources/scc-daemonset.yaml`
+`kubectl apply -f https://raw.githubusercontent.com/nginxinc/nginx-ingress-helm-operator/v1.4.2/resources/scc-daemonset.yaml`
 
 You can now deploy the NGINX Ingress Controller instances.