Argo Rollouts

Procedure

1. Log in to the OpenShift Container Platform web console as a cluster administrator.
2. In the Administrator perspective, click Operators → Installed Operators.
3. Create or select the project where you want to create and configure a RolloutManager custom resource (CR) from the Project drop-down menu.
4. Select Red Hat OpenShift GitOps from the installed operators.
5. In the Details tab, under the Provided APIs section, click Create instance in the RolloutManager pane.

6. On the Create RolloutManager page, select the YAML view and use the default YAML or edit it according to your requirements:

   Example: RolloutManager CR

   apiVersion: argoproj.io/v1alpha1
   kind: RolloutManager
   metadata:
     name: argo-rollout
     labels:
       example: basic
   spec: {}

7. Click Create.
8. In the RolloutManager tab, under the RolloutManagers section, verify that the Status field of the RolloutManager instance shows as Phase: Available.

9. In the left navigation pane, verify the creation of the namespace-scoped supporting resources:

   • Click Workloads → Deployments to verify that the argo-rollouts deployment is available with the Status showing as 1 of 1 pods running.
   • Click Workloads → Secrets to verify that the argo-rollouts-notification-secret secret is available.
   • Click Networking → Services to verify that the argo-rollouts-metrics service is available.
   • Click User Management → Roles to verify that the argo-rollouts role and argo-rollouts-aggregate-to-admin, argo-rollouts-aggregate-to-edit, and argo-rollouts-aggregate-to-view cluster roles are available.
   • Click User Management → RoleBindings to verify that the argo-rollouts role binding is available.

Procedure

1. Log in to the OpenShift Container Platform web console as a cluster administrator.
2. In the Administrator perspective, click Operators → Installed Operators.
3. Click the Project drop-down menu and select the project that contains the RolloutManager CR.
4. Select Red Hat OpenShift GitOps from the installed operators.
5. Click the RolloutManager tab to find RolloutManager instances under the RolloutManagers section.
6. Click the instance.
7. Click Actions → Delete RolloutManager from the drop-down menu, and click Delete to confirm in the dialog box.
8. In the RolloutManager tab, under the RolloutManagers section, verify that the RolloutManager instance is not available anymore.

9. In the left navigation pane, verify the deletion of the namespace-scoped supporting resources:

   • Click Workloads → Deployments to verify that the argo-rollouts deployment is deleted.
   • Click Workloads → Secrets to verify that the argo-rollouts-notification-secret secret is deleted.
   • Click Networking → Services to verify that the argo-rollouts-metrics service is deleted.
   • Click User Management → Roles to verify that the argo-rollouts role and argo-rollouts-aggregate-to-admin, argo-rollouts-aggregate-to-edit, and argo-rollouts-aggregate-to-view cluster roles are deleted.
   • Click User Management → RoleBindings to verify that the argo-rollouts role binding is deleted.

Procedure

1. Download the latest version of the Argo Rollouts CLI binary, kubectl-argo-rollouts, by running the following command:

   $ curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64

2. Ensure that the kubectl-argo-rollouts binary is executable by running the following command:

   $ chmod +x ./kubectl-argo-rollouts-linux-amd64

3. Move the kubectl-argo-rollouts binary to the system path by running the following command:

   # mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

   Important

   Ensure that you have superuser privileges to run this command.

4. Verify that the plugin is installed correctly by running the following command and receiving the similar output:

   $ oc argo rollouts version

   Example output

   kubectl-argo-rollouts: v1.6.6+737ca89
     BuildDate: 2024-02-13T15:39:31Z 1
     GitCommit: 737ca89b42e4791e96e05b438c2b8540737a2a1a
     GitTreeState: clean
     GoVersion: go1.20.14 2
     Compiler: gc
     Platform: linux/amd64 3

   1

   The build date information of the Argo Rollouts binary.

   2

   The version of the Go language used for building the Argo Rollouts binary.

   3

   The platform used for building the Argo Rollouts binary.

Procedure

1. In the Administrator perspective of the web console, click Operators → Installed Operators → Red Hat OpenShift GitOps → Rollout.
2. Create or select the project in which you want to create and configure a Rollout custom resource (CR) from the Project drop-down menu.

3. Click Create Rollout and enter the following configuration in the YAML view:

   apiVersion: argoproj.io/v1alpha1
   kind: Rollout
   metadata:
     name: rollouts-demo
   spec:
     replicas: 5
     strategy:
       canary: 1
         steps: 2
         - setWeight: 20 3
         - pause: {}  4
         - setWeight: 40
         - pause: {duration: 45}  5
         - setWeight: 60
         - pause: {duration: 20}
         - setWeight: 80
         - pause: {duration: 10}
     revisionHistoryLimit: 2
     selector:
       matchLabels:
         app: rollouts-demo
     template: 6
       metadata:
         labels:
           app: rollouts-demo
       spec:
         containers:
         - name: rollouts-demo
           image: argoproj/rollouts-demo:blue
           ports:
           - name: http
             containerPort: 8080
             protocol: TCP
           resources:
             requests:
               memory: 32Mi
               cpu: 5m

   1

   The deployment strategy that the rollout must use.

   2

   Specify the steps for the rollout. This example gradually routes 20%, 40%, 60%, and 80% of traffic to the canary version.

   3

   The percentage of traffic that must be directed to the canary version. A value of 20 means that 20% of traffic is directed to the canary version.

   4

   Specify to the Argo Rollouts controller to pause indefinitely until it finds a request for promotion.

   5

   Specify to the Argo Rollouts controller to pause for a duration of 45 seconds. You can set the duration value in seconds (s), minutes (m), or hours (h). For example, you can specify 1h for an hour. If no value is specified, the duration value defaults to seconds.

   6

   Specifies the pods that are to be created.

4. Click Create.

   Note

   To ensure that the rollout becomes available quickly on creation, the Argo Rollouts controller automatically treats the argoproj/rollouts-demo:blue initial container image specified in the .spec.template.spec.containers.image field as a stable version. In the initial instance, the creation of the Rollout resource routes all of the traffic towards the stable version of the application and skips the part where the traffic is sent to the canary version. However, for all subsequent application upgrades with the modifications to the .spec.template.spec.containers.image field, the Argo Rollouts controller performs the canary steps, as usual.

5. Verify that your rollout was created correctly by running the following command:

   $ oc argo rollouts list rollouts -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   Example output

   NAME           STRATEGY   STATUS        STEP  SET-WEIGHT  READY  DESIRED  UP-TO-DATE  AVAILABLE
   rollouts-demo  Canary     Healthy       8/8   100         5/5    5        5           5

6. Create the Kubernetes services that targets the rollouts-demo rollout.

   1. In the Administrator perspective of the web console, click Networking → Services.

   2. Click Create Service and enter the following configuration in the YAML view:

      apiVersion: v1
      kind: Service
      metadata:
        name: rollouts-demo
      spec:
        ports: 1
        - port: 80
          targetPort: http
          protocol: TCP
          name: http
      
        selector: 2
          app: rollouts-demo

      1

      Specifies the name of the port used by the application for running inside the container.

      2

      Ensure that the contents of the selector field are the same as in the Rollout custom resource (CR).

   3. Click Create.

      Rollouts automatically update the created service with pod template hash of the canary ReplicaSet. For example, rollouts-pod-template-hash: 687d76d795.

7. Watch the progression of your rollout by running the following command:

   $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   Example output

   Name:            rollouts-demo
   Namespace:       spring-petclinic
   Status:          ✔ Healthy
   Strategy:        Canary
     Step:          8/8
     SetWeight:     100
     ActualWeight:  100
   Images:          argoproj/rollouts-demo:blue (stable)
   Replicas:
     Desired:       5
     Current:       5
     Updated:       5
     Ready:         5
     Available:     5
   
   NAME                                       KIND        STATUS     AGE    INFO
   ⟳ rollouts-demo                            Rollout     ✔ Healthy  4m50s
   └──# revision:1
      └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  4m50s  stable
         ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  4m49s  ready:1/1
         ├──□ rollouts-demo-687d76d795-bv5zf  Pod         ✔ Running  4m49s  ready:1/1
         ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  4m49s  ready:1/1
         ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  4m49s  ready:1/1
         └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  4m49s  ready:1/1

   After the rollout has been created, you can verify that the Status field of the rollout shows Phase: Healthy.

8. In the Rollout tab, under the Rollouts section, verify that the Status field of the rollouts-demo rollout shows as Phase: Healthy.

   Tip

   Alternatively, you can verify that the rollout is healthy by running the following command:

   $ oc argo rollouts status rollouts-demo -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   Example output

   Healthy

Procedure

1. Simulate the new canary version of the application by modifying the container image deployed in the rollout.

   1. In the Administrator perspective of the web console, go to Operators → Installed Operators → Red Hat OpenShift GitOps → Rollout.
   2. Select the existing rollouts-demo rollout and modify the .spec.template.spec.containers.image value from argoproj/rollouts-demo:blue to argoproj/rollouts-demo:yellow in the YAML view.

   3. Click Save and then click Reload.

      The container image deployed in the rollout is modified and the rollout initiates a new canary deployment.

      Note

      As per the setWeight property defined in the .spec.strategy.canary.steps field of the Rollout CR, initially 20% of traffic to the route reaches the canary version and the rollout is paused indefinitely until a request for promotion is received.

      Example route with 20% of traffic directed to the canary version and rollout is paused indefinitely until a request for promotion is specified in the subsequent step

      spec:
        replicas: 5
        strategy:
          canary: 1
            steps: 2
            - setWeight: 20 3
            - pause: {}  4
        # (...)

      1

      The deployment strategy that the rollout must use.

      2

      The steps for the rollout. This example gradually routes 20%, 40%, 60%, and 80% of traffic to the canary version.

      3

      The percentage of traffic that must be directed to the canary version. A value of 20 means that 20% of traffic is directed to the canary version.

      4

      Specification to the Argo Rollouts controller to pause indefinitely until it finds a request for promotion.

2. Watch the progression of your rollout by running the following command:

   $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

   1

   Specify the namespace where the Rollout CR is defined.

   Example output

   Name:            rollouts-demo
   Namespace:       spring-petclinic
   Status:          ॥ Paused
   Message:         CanaryPauseStep
   Strategy:        Canary
     Step:          1/8
     SetWeight:     20
     ActualWeight:  20
   Images:          argoproj/rollouts-demo:blue (stable)
                    argoproj/rollouts-demo:yellow (canary)
   Replicas:
     Desired:       5
     Current:       5
     Updated:       1
     Ready:         5
     Available:     5
   
   NAME                                       KIND        STATUS     AGE    INFO
   ⟳ rollouts-demo                            Rollout     ॥ Paused   9m51s
   ├──# revision:2
   │  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy  99s    canary
   │     └──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running  98s    ready:1/1
   └──# revision:1
      └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  9m51s  stable
         ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  9m50s  ready:1/1
         ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  9m50s  ready:1/1
         ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  9m50s  ready:1/1
         └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  9m50s  ready:1/1

   The rollout is now in a paused status, because there is no pause duration specified in the rollout’s update strategy configuration.

3. Repeat the previous step to test the newly deployed version of application and ensure that it is working as expected. For example, verify the application by interacting with the application through the browser and try running tests or observing container logs.

   The rollout will remain paused until you advance it to the next step.

Procedure

1. Simulate another new canary version of the application by running the following command in the Argo Rollouts CLI:

   $ oc argo rollouts promote rollouts-demo -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   Example output

   rollout 'rollouts-demo' promoted

   This increases the traffic weight to 40% in the canary version.

2. Verify that the rollout progresses through the rest of the steps, by running the following command:

   $ oc argo rollouts get rollout rollouts-demo -n <namespace> --watch 1

   1

   Specify the namespace where the Rollout resource is defined.

   Because the rest of the steps as defined in the Rollout CR have set durations, for example, pause: {duration: 45}, the Argo Rollouts controller waits that duration and then automatically moves to the next step.

   After all steps are completed successfully, the new ReplicaSet object is marked as the stable replica set.

   Example output

   Name:            rollouts-demo
   Namespace:       spring-petclinic
   Status:          ✔ Healthy
   Strategy:        Canary
     Step:          8/8
     SetWeight:     100
     ActualWeight:  100
   Images:          argoproj/rollouts-demo:yellow (stable)
   Replicas:
     Desired:       5
     Current:       5
     Updated:       5
     Ready:         5
     Available:     5
   
   NAME                                       KIND        STATUS        AGE   INFO
   ⟳ rollouts-demo                            Rollout     ✔ Healthy     14m
   ├──# revision:2
   │  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy     6m5s  stable
   │     ├──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running     6m4s  ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-g9kd5  Pod         ✔ Running     2m4s  ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-2ptpp  Pod         ✔ Running     78s   ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-tmk6c  Pod         ✔ Running     58s   ready:1/1
   │     └──□ rollouts-demo-6cf78c66c5-zv6lx  Pod         ✔ Running     47s   ready:1/1
   └──# revision:1
      └──⧉ rollouts-demo-687d76d795           ReplicaSet  • ScaledDown  14m

Procedure

1. Update the container image version and and modify the .spec.template.spec.containers.image value from argoproj/rollouts-demo:yellow to argoproj/rollouts-demo:red by running the following command in the Argo Rollouts CLI:

   $ oc argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:red -n <namespace> 1

   1

   Specify the namespace where the Rollout custom resource (CR) is defined.

   Example output

   rollout "rollouts-demo" image updated

   The container image deployed in the rollout is modified and the rollout initiates a new canary deployment.

2. Wait for the rollout to reach the paused status.

3. Verify that the rollout deploys the rollouts-demo:red canary version and reaches the paused status by running the following command:

   $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

   1

   Specify the namespace where the Rollout CR is defined.

   Example output

   Name:            rollouts-demo
   Namespace:       spring-petclinic
   Status:          ॥ Paused
   Message:         CanaryPauseStep
   Strategy:        Canary
     Step:          1/8
     SetWeight:     20
     ActualWeight:  20
   Images:          argoproj/rollouts-demo:red (canary)
                    argoproj/rollouts-demo:yellow (stable)
   Replicas:
     Desired:       5
     Current:       5
     Updated:       1
     Ready:         5
     Available:     5
   
   NAME                                       KIND        STATUS        AGE    INFO
   ⟳ rollouts-demo                            Rollout     ॥ Paused      17m
   ├──# revision:3
   │  └──⧉ rollouts-demo-5747959bdb           ReplicaSet  ✔ Healthy     75s    canary
   │     └──□ rollouts-demo-5747959bdb-fdrsg  Pod         ✔ Running     75s    ready:1/1
   ├──# revision:2
   │  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy     9m45s  stable
   │     ├──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running     9m44s  ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-2ptpp  Pod         ✔ Running     4m58s  ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-tmk6c  Pod         ✔ Running     4m38s  ready:1/1
   │     └──□ rollouts-demo-6cf78c66c5-zv6lx  Pod         ✔ Running     4m27s  ready:1/1
   └──# revision:1
      └──⧉ rollouts-demo-687d76d795           ReplicaSet  • ScaledDown  17m

4. Abort the update of the rollout by running the following command:

   $ oc argo rollouts abort rollouts-demo -n <namespace> 1

   1

   Specify the namespace where the Rollout CR is defined.

   Example output

   rollout 'rollouts-demo' aborted

   The Argo Rollouts controller deletes the canary resources of the application, and rolls back to the stable version.

5. Verify that after aborting the rollout, now the canary ReplicaSet is scaled to 0 replicas by running the following command:

   $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

   1

   Specify the namespace where the Rollout CR is defined.

   Example output

   Name:            rollouts-demo
   Namespace:       spring-petclinic
   Status:          ✖ Degraded
   Message:         RolloutAborted: Rollout aborted update to revision 3
   Strategy:        Canary
     Step:          0/8
     SetWeight:     0
     ActualWeight:  0
   Images:          argoproj/rollouts-demo:yellow (stable)
   Replicas:
     Desired:       5
     Current:       5
     Updated:       0
     Ready:         5
     Available:     5
   
   NAME                                       KIND        STATUS        AGE    INFO
   ⟳ rollouts-demo                            Rollout     ✖ Degraded    24m
   ├──# revision:3
   │  └──⧉ rollouts-demo-5747959bdb           ReplicaSet  • ScaledDown  7m38s  canary
   ├──# revision:2
   │  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy     16m    stable
   │     ├──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running     16m    ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-2ptpp  Pod         ✔ Running     11m    ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-tmk6c  Pod         ✔ Running     11m    ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-zv6lx  Pod         ✔ Running     10m    ready:1/1
   │     └──□ rollouts-demo-6cf78c66c5-mlbsh  Pod         ✔ Running     4m47s  ready:1/1
   └──# revision:1
      └──⧉ rollouts-demo-687d76d795           ReplicaSet  • ScaledDown  24m

   The rollout status is marked as Degraded indicating that even though the application has rolled back to the previous stable version, yellow, the rollout is not currently at the wanted version, red, that was set within the .spec.template.spec.containers.image field.

   Note

   The Degraded status does not reflect the health of the application. It only indicates that there is a mismatch between the wanted and running container image versions.

6. Update the container image version to the previous stable version, yellow, and modify the .spec.template.spec.containers.image value by running the following command:

   $ oc argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow -n <namespace> 1

   1

   Specify the namespace where the Rollout CR is defined.

   Example output

   rollout "rollouts-demo" image updated

   The rollout skips the analysis and promotion steps, rolls back to the previous stable version, yellow, and fast-tracks the deployment of the stable ReplicaSet.

7. Verify that the rollout status is immediately marked as Healthy by running the following command:

   $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

   1

   Specify the namespace where the Rollout CR is defined.

   Example output

   Name:            rollouts-demo
   Namespace:       spring-petclinic
   Status:          ✔ Healthy
   Strategy:        Canary
     Step:          8/8
     SetWeight:     100
     ActualWeight:  100
   Images:          argoproj/rollouts-demo:yellow (stable)
   Replicas:
     Desired:       5
     Current:       5
     Updated:       5
     Ready:         5
     Available:     5
   
   NAME                                       KIND        STATUS        AGE  INFO
   ⟳ rollouts-demo                            Rollout     ✔ Healthy     63m
   ├──# revision:4
   │  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy     55m  stable
   │     ├──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running     55m  ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-2ptpp  Pod         ✔ Running     50m  ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-tmk6c  Pod         ✔ Running     50m  ready:1/1
   │     ├──□ rollouts-demo-6cf78c66c5-zv6lx  Pod         ✔ Running     50m  ready:1/1
   │     └──□ rollouts-demo-6cf78c66c5-mlbsh  Pod         ✔ Running     44m  ready:1/1
   ├──# revision:3
   │  └──⧉ rollouts-demo-5747959bdb           ReplicaSet  • ScaledDown  46m
   └──# revision:1
      └──⧉ rollouts-demo-687d76d795           ReplicaSet  • ScaledDown  63m

Procedure

1. Create a Route object.

   1. In the Administrator perspective of the web console, click Networking → Routes.
   2. Click Create Route.

   3. On the Create Route page, click YAML view and add the following snippet: The following example creates a route called rollouts-demo-route:

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: rollouts-demo-route
      spec:
        port:
          targetPort: http 1
        tls: 2
          insecureEdgeTerminationPolicy: Redirect
          termination: edge
        to:
          kind: Service
          name: argo-rollouts-stable-service 3
          weight: 100 4
      
        alternateBackends:
          - kind: Service
            name: argo-rollouts-canary-service 5
            weight: 0 6

      1

      Specifies the name of the port used by the application for running inside the container.

      2

      Specifies the TLS configuration used to secure the route.

      3

      The name of the targeted stable service.

      4

      This field is automatically modified to stable weight by Route Rollout plugin.

      5

      The name of the targeted canary service.

      6

      This field is automatically modified to canary weight by Route Rollout plugin.

   4. Click Create to create the route. It is then displayed on the Routes page.

2. Create the services, canary and stable, to be referenced in the route.

   1. In the Administrator perspective of the web console, click Networking → Services.
   2. Click Create Service.

   3. On the Create Service page, click YAML view and add the following snippet: The following example creates a canary service called argo-rollouts-canary-service. Canary traffic is directed to this service.

      apiVersion: v1
      kind: Service
      metadata:
        name: argo-rollouts-canary-service
      spec:
        ports: 1
        - port: 80
          targetPort: http
          protocol: TCP
          name: http
      
        selector: 2
          app: rollouts-demo

      1

      Specifies the name of the port used by the application for running inside the container.

      2

      Ensure that the contents of the selector field are the same as in stable service and Rollout custom resource (CR).

      Important

      Ensure that the name of the canary service specified in the Route object matches with the name of the canary service specified in the Service object.

   4. Click Create to create the canary service.

      Rollouts automatically update the created service with pod template hash of the canary ReplicaSet. For example, rollouts-pod-template-hash: 7bf84f9696.

   5. Repeat these steps to create the stable service: The following example creates a stable service called argo-rollouts-stable-service. Stable traffic is directed to this service.

      apiVersion: v1
      kind: Service
      metadata:
        name: argo-rollouts-stable-service
      spec:
        ports: 1
        - port: 80
          targetPort: http
          protocol: TCP
          name: http
      
        selector: 2
          app: rollouts-demo

      1

      Specifies the name of the port used by the application for running inside the container.

      2

      Ensure that the contents of the selector field are the same as in canary service and Rollout CR .

      Important

      Ensure that the name of the stable service specified in the Route object matches with the name of the stable service specified in the Service object.

   6. Click Create to create the stable service.

      Rollouts automatically update the created service with pod template hash of the stable ReplicaSet. For example, rollouts-pod-template-hash: 1b6a7733.

3. Create the Rollout CR to reference the Route and Service objects.

   1. In the Administrator perspective of the web console, go to Operators → Installed Operators → Red Hat OpenShift GitOps → Rollout.

   2. On the Create Rollout page, click YAML view and add the following snippet: The following example creates a Rollout CR called rollouts-demo:

      apiVersion: argoproj.io/v1alpha1
      kind: Rollout
      metadata:
        name: rollouts-demo
      spec:
        template: 1
          metadata:
            labels:
              app: rollouts-demo
          spec:
            containers:
            - name: rollouts-demo
              image: argoproj/rollouts-demo:blue
              ports:
              - name: http
                containerPort: 8080
                protocol: TCP
              resources:
                requests:
                  memory: 32Mi
                  cpu: 5m
      
        revisionHistoryLimit: 2
        replicas: 5
        strategy:
          canary:
            canaryService: argo-rollouts-canary-service 2
            stableService: argo-rollouts-stable-service 3
            trafficRouting:
              plugins:
                argoproj-labs/openshift:
                  routes:
                    - rollouts-demo-route  4
            steps: 5
            - setWeight: 30
            - pause: {}
            - setWeight: 60
            - pause: {}
        selector: 6
          matchLabels:
            app: rollouts-demo

      1

      Specifies the pods that are to be created.

      2

      This value must match the name of the created canary Service.

      3

      This value must match the name of the created stable Service.

      4

      This value must match the name of the created Route CR.

      5

      Specify the steps for the rollout. This example gradually routes 30%, 60%, and 100% of traffic to the canary version.

      6

      Ensure that the contents of the selector field are the same as in canary and stable service.

   3. Click Create.
   4. In the Rollout tab, under the Rollout section, verify that the Status field of the rollout shows Phase: Healthy.

4. Verify that the route is directing 100% of the traffic towards the stable version of the application.

   Note

   When the first instance of the Rollout resource is created, the rollout regulates the amount of traffic to be directed towards the stable and canary application versions. In the initial instance, the creation of the Rollout resource routes all of the traffic towards the stable version of the application and skips the part where the traffic is sent to the canary version.

   1. Go to Networking → Routes and look for the Route resource you want to verify.

   2. Select the YAML tab and view the following snippet:

      Example: Route

      kind: Route
      metadata:
        name: rollouts-demo-route
      spec:
        alternateBackends:
        - kind: Service
          name: argo-rollouts-canary-service
          weight: 0 1
        # (...)
        to:
          kind: Service
          name: argo-rollouts-stable-service
          weight: 100 2

      1

      A value of 0 means that 0% of traffic is directed to the canary version.

      2

      A value of 100 means that 100% of traffic is directed to the stable version.

5. Simulate the new canary version of the application by modifying the container image deployed in the rollout.

   1. In the Administrator perspective of the web console, go to Operators → Installed Operators → Red Hat OpenShift GitOps → Rollout.

   2. Select the existing Rollout and modify the .spec.template.spec.containers.image value from argoproj/rollouts-demo:blue to argoproj/rollouts-demo:yellow.

      As a result, the container image deployed in the rollout is modified and the rollout initiates a new canary deployment.

      Note

      As per the setWeight property defined in the .spec.strategy.canary.steps field of the Rollout resource, initially 30% of traffic to the route reaches the canary version and 70% of traffic is directed towards the stable version. The rollout is paused after 30% of traffic is directed to the canary version.

      Example route with 30% of traffic directed to the canary version and 70% directed to the stable version.

      spec:
        alternateBackends:
        - kind: Service
          name: argo-rollouts-canary-service
          weight: 30
        # (...)
        to:
          kind: Service
          name: argo-rollouts-stable-service
          weight: 70

6. Simulate another new canary version of the application by running the following command in the Argo Rollouts CLI:

   $ oc argo rollouts promote rollouts-demo -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   This increases the traffic weight to 60% in the canary version and 40% in the stable version.

   Example route with 60% of traffic directed to the canary version and 40% directed to the stable version.

   spec:
     alternateBackends:
     - kind: Service
       name: argo-rollouts-canary-service
       weight: 60
     # (...)
     to:
       kind: Service
       name: argo-rollouts-stable-service
       weight: 40

7. Increase the traffic weight in the canary version to 100% and discard the traffic in the old stable version of the application by running the following command:

   $ oc argo rollouts promote rollouts-demo -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   Example route with 0% of traffic directed to the canary version and 100% directed to the stable version.

   spec:
     # (...)
     to:
       kind: Service
       name: argo-rollouts-stable-service
       weight: 100

Procedure

1. Create a Gateway object to accept the inbound traffic for your mesh.

   1. Create a YAML file with the following snippet content.

      Example gateway called rollouts-demo-gateway

      apiVersion: networking.istio.io/v1alpha3
      kind: Gateway
      metadata:
        name: rollouts-demo-gateway 1
      spec:
        selector:
          istio: ingressgateway 2
        servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*"

      1

      The name of the gateway.

      2

      Specifies the name of the ingress gateway. The gateway configures exposed ports and protocols but does not include any traffic routing configuration.

   2. Apply the YAML file by running the following command.

      $ oc apply -f gateway.yaml

2. Create the services for the canary and stable versions of the application.

   1. In the Administrator perspective of the web console, go to Networking → Services.
   2. Click Create Service.

   3. On the Create Service page, click YAML view and add the following snippet. The following example creates a stable service called rollouts-demo-stable. Stable traffic is directed to this service.

      apiVersion: v1
      kind: Service
      metadata:
        name: rollouts-demo-stable
      spec:
        ports: 1
        - port: 80
          targetPort: http
          protocol: TCP
          name: http
        selector: 2
          app: rollouts-demo

      1

      Specifies the name of the port used by the application for running inside the container.

      2

      Ensure that the contents of the selector field are the same in stable service and Rollout CR.

   4. Click Create to create a stable service.

   5. On the Create Service page, click YAML view and add the following snippet. The following example creates a canary service called rollouts-demo-canary. Canary traffic is directed to this service.

      apiVersion: v1
      kind: Service
      metadata:
        name: rollouts-demo-canary
      spec:
        ports: 1
        - port: 80
          targetPort: http
          protocol: TCP
          name: http
        selector: 2
          app: rollouts-demo

      1

      Specifies the name of the port used by the application for running inside the container.

      2

      Ensure that the contents of the selector field are the same in canary service and Rollout CR.

   6. Click Create to create the canary service.

3. Create a VirtualService to route incoming traffic to stable and canary services.

   1. Create a YAML file, and copy the following YAML into it. The following example creates a VirtualService called rollouts-demo-vsvc:

      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: rollouts-demo-vsvc
      spec:
        gateways:
        - rollouts-demo-gateway 1
        hosts:
        - rollouts-demo-vsvc.local
        http:
        - name: primary
          route:
          - destination:
              host: rollouts-demo-stable 2
              port:
                number: 15372 3
            weight: 100
          - destination:
              host: rollouts-demo-canary 4
              port:
                number: 15372
            weight: 0
        tls: 5
        - match:
          - port: 3000
            sniHosts:
            - rollouts-demo-vsvc.local
          route:
          - destination:
              host: rollouts-demo-stable
            weight: 100
          - destination:
              host: rollouts-demo-canary
            weight: 0

      1

      The name of the gateway.

      2

      The name of the targeted stable service.

      3

      Specifies the port number used for listening to traffic.

      4

      The name of the targeted canary service.

      5

      Specifies the TLS configuration used to secure the VirtualService.

   2. Apply the YAML file by running the following command.

      $ oc apply -f virtual-service.yaml

4. Create the Rollout CR. In this example, Istio is used as a traffic manager.

   1. In the Administrator perspective of the web console, go to Operators → Installed Operators → Red Hat OpenShift GitOps → Rollout.

   2. On the Create Rollout page, click YAML view and add the following snippet. The following example creates a Rollout CR called rollouts-demo:

      apiVersion: argoproj.io/v1alpha1
      kind: Rollout
      metadata:
        name: rollouts-demo
      spec:
        replicas: 5
        strategy:
          canary:
            canaryService: rollouts-demo-canary 1
            stableService: rollouts-demo-stable 2
            trafficRouting:
              istio:
                virtualServices:
                - name: rollouts-demo-vsvc
                  routes:
                  - primary
            steps: 3
            - setWeight: 20
            - pause: {}
            - setWeight: 40
            - pause: {}
            - setWeight: 60
            - pause: {duration: 30}
            - setWeight: 80
            - pause: {duration: 60}
        revisionHistoryLimit: 2
        selector: 4
          matchLabels:
            app: rollouts-demo
        template:
          metadata:
            labels:
              app: rollouts-demo
              istio-injection: enabled
          spec:
            containers:
            - name: rollouts-demo
              image: argoproj/rollouts-demo:blue
              ports:
              - name: http
                containerPort: 8080
                protocol: TCP
              resources:
                requests:
                  memory: 32Mi
                  cpu: 5m

      1

      This value must match the name of the created canary Service.

      2

      This value must match the name of the created stable Service.

      3

      Specify the steps for the rollout. This example gradually routes 20%, 40%, 60%, and 100% of traffic to the canary version.

      4

      Ensure that the contents of the selector field are the same as in canary and stable service.

   3. Click Create.
   4. In the Rollout tab, under the Rollout section, verify that the Status field of the rollout shows Phase: Healthy.

5. Verify that the route is directing 100% of the traffic towards the stable version of the application.

   1. Watch the progression of your rollout by running the following command:

      $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

      1

      Specify the namespace where the Rollout resource is defined.

      Example output

      Name:            rollouts-demo
      Namespace:       argo-rollouts
      Status:          ✔ Healthy
      Strategy:        Canary
        Step:          8/8
        SetWeight:     100
        ActualWeight:  100
      Images:          argoproj/rollouts-demo:blue (stable)
      Replicas:
        Desired:       5
        Current:       5
        Updated:       5
        Ready:         5
        Available:     5
      
      NAME                                       KIND        STATUS     AGE    INFO
      ⟳ rollouts-demo                            Rollout     ✔ Healthy  4m50s
      └──# revision:1
         └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  4m50s  stable
            ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  4m49s  ready:1/1
            ├──□ rollouts-demo-687d76d795-bv5zf  Pod         ✔ Running  4m49s  ready:1/1
            ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  4m49s  ready:1/1
            ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  4m49s  ready:1/1
            └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  4m49s  ready:1/1

      Note

      When the first instance of the Rollout resource is created, the rollout regulates the amount of traffic to be directed towards the stable and canary application versions. In the initial instance, the creation of the Rollout resource routes all of the traffic towards the stable version of the application and skips the part where the traffic is sent to the canary version.

   2. To verify that the service mesh sends 100% of the traffic for the stable service and 0% for the canary service, run the following command:

      $ oc describe virtualservice/rollouts-demo-vsvc -n <namespace>

   3. View the following output displayed in the terminal:

      route
      - destination:
          host: rollouts-demo-stable
        weight: 100 1
      - destination:
          host: rollouts-demo-canary
        weight: 0 2

      1

      A value of 100 means that 100% of traffic is directed to the stable version.

      2

      A value of 0 means that 0% of traffic is directed to the canary version.

6. Simulate the new canary version of the application by modifying the container image deployed in the rollout.

   1. Modify the .spec.template.spec.containers.image value from argoproj/rollouts-demo:blue to argoproj/rollouts-demo:yellow, by running the following command.

      $ oc argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow -n <namespace>

      As a result, the container image deployed in the rollout is modified and the rollout initiates a new canary deployment.

      Note

      As per the setWeight property defined in the .spec.strategy.canary.steps field of the Rollout resource, initially 20% of traffic to the route reaches the canary version and 80% of traffic is directed towards the stable version. The rollout is paused after 20% of traffic is directed to the canary version.

   2. Watch the progression of your rollout by running the following command.

      $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

      1

      Specify the namespace where the Rollout resource is defined.

      In the following example, 80% of traffic is routed to the stable service and 20% of traffic is routed to the canary service. The deployment is then paused indefinitely until you manually promote it to the next level.

      Example output

      Name:            rollouts-demo
      Namespace:       argo-rollouts
      Status:          ॥ Paused
      Message:         CanaryPauseStep
      Strategy:        Canary
        Step:          1/8
        SetWeight:     20
        ActualWeight:  20
      Images:          argoproj/rollouts-demo:blue (stable)
                       argoproj/rollouts-demo:yellow (canary)
      Replicas:
        Desired:       5
        Current:       6
        Updated:       1
        Ready:         6
        Available:     6
      
      NAME                                       KIND        STATUS     AGE    INFO
      ⟳ rollouts-demo                            Rollout     ॥ Paused   6m51s
      ├──# revision:2
      │  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy  99s    canary
      │     └──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running  98s    ready:1/1
      └──# revision:1
         └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  9m51s  stable
            ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  9m50s  ready:1/1
            ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  9m50s  ready:1/1
            ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  9m50s  ready:1/1
            └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  9m50s  ready:1/1

      Example with 80% directed to the stable version and 20% of traffic directed to the canary version.

      route
      - destination:
          host: rollouts-demo-stable
        weight: 80 1
      - destination:
          host: rollouts-demo-canary
        weight: 20 2

      1

      A value of 80 means that 80% of traffic is directed to the stable version.

      2

      A value of 20 means that 20% of traffic is directed to the canary version.

7. Manually promote the deployment to the next promotion step.

   $ oc argo rollouts promote rollouts-demo -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   1. Watch the progression of your rollout by running the following command:

      $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

      1

      Specify the namespace where the Rollout resource is defined.

      In the following example, 60% of traffic is routed to the stable service and 40% of traffic is routed to the canary service. The deployment is then paused indefinitely until you manually promote it to the next level.

      Example output

      Name:            rollouts-demo
      Namespace:       argo-rollouts
      Status:          ॥ Paused
      Message:         CanaryPauseStep
      Strategy:        Canary
        Step:          3/8
        SetWeight:     40
        ActualWeight:  40
      Images:          argoproj/rollouts-demo:blue (stable)
                       argoproj/rollouts-demo:yellow (canary)
      Replicas:
        Desired:       5
        Current:       7
        Updated:       2
        Ready:         7
        Available:     7
      
      NAME                                       KIND        STATUS     AGE    INFO
      ⟳ rollouts-demo                            Rollout     ॥ Paused   9m21s
      ├──# revision:2
      │  └──⧉ rollouts-demo-6cf78c66c5           ReplicaSet  ✔ Healthy  99s    canary
      │     └──□ rollouts-demo-6cf78c66c5-zrgd4  Pod         ✔ Running  98s    ready:1/1
      └──# revision:1
         └──⧉ rollouts-demo-687d76d795           ReplicaSet  ✔ Healthy  9m51s  stable
            ├──□ rollouts-demo-687d76d795-75k57  Pod         ✔ Running  9m50s  ready:1/1
            ├──□ rollouts-demo-687d76d795-jsxg8  Pod         ✔ Running  9m50s  ready:1/1
            ├──□ rollouts-demo-687d76d795-rsgtv  Pod         ✔ Running  9m50s  ready:1/1
            └──□ rollouts-demo-687d76d795-xrmrj  Pod         ✔ Running  9m50s  ready:1/1

      Example of 60% traffic directed to the stable version and 40% directed to the canary version.

      route
      - destination:
          host: rollouts-demo-stable
        weight: 60 1
      - destination:
          host: rollouts-demo-canary
        weight: 40 2

      1

      A value of 60 means that 60% of traffic is directed to the stable version.

      2

      A value of 40 means that 40% of traffic is directed to the canary version.

8. Increase the traffic weight in the canary version to 100% and discard the traffic in the previous stable version of the application by running the following command:

   $ oc argo rollouts promote rollouts-demo -n <namespace> 1

   1

   Specify the namespace where the Rollout resource is defined.

   1. Watch the progression of your rollout by running the following command:

      $ oc argo rollouts get rollout rollouts-demo --watch -n <namespace> 1

      1

      Specify the namespace where the Rollout resource is defined.

Procedure

1. In the Administrator perspective of the web console, go to Administration → CustomResourceDefinitions.
2. Search for Subscription and click the Subscription CRD.
3. Click the Instances tab and then click the openshift-gitops-operator subscription.

4. Click the YAML tab and edit the YAML file.

   1. Specify the NAMESPACE_SCOPED_ARGO_ROLLOUTS environment variable, with the value set to true in the .spec.config.env property.

      Example of configuring the namespace-scoped Argo Rollouts installation

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-gitops-operator
      spec:
        # (...)
        config:
          env:
            - name: NAMESPACE_SCOPED_ARGO_ROLLOUTS
              value: 'true' 1

      1

      The value set to 'true' enables namespace-scoped installation. If the value is set to 'false' or not specified the installation defaults to cluster-scoped mode.

   2. Click Save.

      The Red Hat OpenShift GitOps Operator facilitates the reconciliation of the Argo Rollouts custom resource within a namespace-scoped installation.

5. Verify that the Red Hat OpenShift GitOps Operator has enabled the namespace-scoped Argo Rollouts installation by viewing the logs of the GitOps container:

   1. In the Administrator perspective of the web console, go to Workloads → Pods.
   2. Click the openshift-gitops-operator-controller-manager pod, and then click the Logs tab.
   3. Look for the following log statement: Running in namespaced-scoped mode. This statement indicates that the Red Hat OpenShift GitOps Operator has enabled the namespace-scoped Argo Rollouts installation.

6. Create a RolloutManager resource to complete the namespace-scoped Argo Rollouts installation:

   1. Go to Operators → Installed Operators → Red Hat OpenShift GitOps, and click the RolloutManager tab.
   2. Click Create RolloutManager.

   3. Select YAML view and enter the following snippet:

      Example RolloutManager CR for a namespace-scoped Argo Rollouts installation

      apiVersion: argoproj.io/v1alpha1
      kind: RolloutManager
      metadata:
        name: rollout-manager
        namespace: my-application 1
      spec:
        namespaceScoped: true

      1

      Specify the name of the project where you want to install the namespace-scoped Argo Rollouts instance.

   4. Click Create.

      After the RolloutManager CR is created, Red Hat OpenShift GitOps begins to install the namespace-scoped Argo Rollouts instance into the selected namespace.

7. Verify that the namespace-scoped installation is successful.

   1. In the RolloutManager tab, under the RolloutManagers section, ensure that the Status field of the RolloutManager instance is Phase: Available.

   2. Examine the following output in the YAML tab under the RolloutManagers section to ensure that the installation is successful:

      Example of namespace-scoped Argo Rollouts installation YAML file

      spec:
        namespaceScoped: true
      status:
        conditions:
          lastTransitionTime: '2024-07-10T14:20:5z`
          message: ''
          reason: Success
          status: 'True' 1
          type: 'Reconciled'
        phase: Available
        rolloutController: Available

      1

      This status indicates that the namespace-scoped Argo Rollouts installation is enabled successfully.

      If you try to install a namespace-specific Argo Rollouts instance while a cluster-scoped installation already exists on the cluster, an error message is displayed:

      Example of an incorrect installation with an error message

      spec:
        namespaceScoped: true
      status:
        conditions:
         lastTransitionTime: '2024-07-10T14:10:7z`
         message: 'when Subscription has environment variable NAMESPACE_SCOPED_ARGO_ROLLOUTS set to False, there may not exist any namespace-scoped RolloutManagers: only a single cluster-scoped RolloutManager is supported'
         reason: InvalidRolloutManagerScope
         status: 'False' 1
         type: 'Reconciled'
        phase: Failure
        rolloutController: Failure

      1

      This status indicates that the namespace-scoped Argo Rollouts installation is not enabled successfully. The installation defaults to cluster-scoped mode.

Procedure

1. Log in to the OpenShift Container Platform web console as a cluster administrator.
2. In the Administrator perspective, click Operators → Installed Operators.
3. Create or select the project where you want to create and configure a RolloutManager custom resource (CR) from the Project drop-down menu.
4. Select Red Hat OpenShift GitOps from the Installed Operators.
5. In the Details tab, under the Provided APIs section, click Create instance in the RolloutManager pane.

6. On the Create RolloutManager page, select the YAML view and edit the YAML.

   Example adding the traffic management and metric plugins configuration in the RolloutManager CR

   apiVersion: argoproj.io/v1alpha1
   kind: RolloutManager
   metadata:
     name: argo-rollouts
   spec:
     plugins:
       trafficManagement:
         - name: argoproj-labs/gatewayAPI 1
           location: https://github.com/sample-metric-plugin 2
       metric:
         - name: argoproj-labs/sample-prometheus 3
           location: https://github.com/sample-trafficrouter-plugin 4
           sha256: dac10cbf57633c9832a17f8c27d2ca34aa97dd3d 5

   1

   Specifies the name of the trafficManagement plugin.

   2

   Specifies the location of the trafficManagement plugin.

   3

   Specifies the name of the metric plugin.

   4

   Specifies the location of the metric plugin.

   5

   Optional: Specifies the SHA256 signature of the plugin binary, which is downloaded and installed by the Rollouts controller.

7. Click Create.
8. In the RolloutManager tab, under the RolloutManagers section, verify that the Status field of the RolloutManager instance shows as Phase: Available.

9. Verify that the traffic management and metric plugins are installed correctly by completing the following steps:

   1. In the Administrator perspective, click Workloads → ConfigMaps.

   2. Click the argo-rollouts-config config map.

      As a result, the plugins defined in the RolloutManager CR are updated in the argo-rollouts-config config map.

      Example updated traffic management and metric plugins in the argo-rollouts-config ConfigMap

      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: argo-rollouts-config
        namespace: argo-rollouts
        labels:
          app.kubernetes.io/component: argo-rollouts
          app.kubernetes.io/name: argo-rollouts
          app.kubernetes.io/part-of: argo-rollouts
      data:
        metricPlugins: |
            - name: "argoproj-labs/sample-prometheus" 1
              location: https://github.com/sample-metric-plugin 2
              sha256: dac10cbf57633c9832a17f8c27d2ca34aa97dd3d 3
        trafficRouterPlugins: |
          - name: argoproj-labs/gatewayAPI 4
            location: https://github.com/sample-metric-plugin 5
            sha256: "" 6
          - name: argoproj-labs/openshift 7
            location: file:/plugins/rollouts-trafficrouter-openshift/openshift-route-plugin 8
            sha256: "" 9

      1

      Specifies the name of the metric plugin.

      2

      Specifies the location of the metric plugin.

      3

      Specifies the sha256 signature of the metric plugin.

      4

      Specifies the name of the trafficmanagement plugin.

      5

      Specifies the location of the trafficmanagement plugin.

      6

      Specifies the sha256 signature of the trafficmanagement plugin.

      7

      Specifies the name of the default trafficmanagement plugin.

      8

      Specifies the location of the default trafficmanagement plugin.

      9

      Specifies the sha256 signature of the trafficmanagement plugin.

   By configuring traffic and metric plugins directly through the RolloutManager CR, you streamline the rollout process, reduce the chance of errors, and ensure consistent plugin management across your environment. This enhances control and flexibility while simplifying deployment procedures.

Procedure

1. Log in to the OpenShift Container Platform web console as a cluster administrator.
2. In the Administrator perspective, click Operators → Installed Operators.
3. Create or select the project where you want to create and configure a RolloutManager CR from the Project drop-down menu.
4. Select Red Hat OpenShift GitOps from the installed Operators.
5. In the Details tab, under the Provided APIs section, click Create instance in the RolloutManager pane.

6. On the Create RolloutManager page, select the YAML view and edit the YAML.

   Example enabling the ha field in the RolloutManager CR

   apiVersion: argoproj.io/v1alpha1
   kind: RolloutManager
   metadata:
     name: argo-rollouts
     namespace: openshift-gitops
   spec:
     ha:
       enabled: true 1

   1

   Specifies whether high availability is enabled or not. If the value is set to true, high availability is enabled.

7. Click Create.
8. In the RolloutManager tab, under the RolloutManagers section, verify that the Status field of the RolloutManager instance shows Phase: Available.

9. Verify the status of the Rollouts deployment by completing the following steps:

   1. In the Administrator perspective, click Workloads → Deployments.
   2. Click the argo-rollouts deployment.
   3. Click the Details tab and confirm that the number of replicas in the Rollouts deployment is now set to 2.

   4. Click the YAML tab and confirm that the following configuration is displayed:

      Example Argo Rollouts deployment configuration file

      kind: Deployment
      metadata:
        name: argo-rollouts
        namespace: openshift-gitops
      spec:
        replicas: 2 1
        selector:
          matchLabels:
            app.kubernetes.io/name: argo-rollouts
        template:
          metadata:
            creationTimestamp: null
            labels:
              app.kubernetes.io/name: argo-rollouts
          spec:
            containers:
                args:
                  - '--leader-elect'
                  - 'true' 2

      1

      Specifies the number of pods.

      2

      Specifies that the --leader-elect=true flag is passed to the Rollouts deployment. Although this flag is set to true by default, explicitly setting it ensures that leader election remains consistently enforced.

Procedure

1. In the Administrator perspective of the web console, navigate to Operators → Installed Operators → Red Hat OpenShift GitOps → Subscription.
2. Click the Actions list and then click Edit Subscription.

3. On the openshift-gitops-operator Subscription details page, under the YAML tab, edit the Subscription YAML file by adding the namespace of the Argo CD instance to the CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES environment variable in the spec section:

   Example configuring the CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES environment variable

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-gitops-operator
   spec:
     config:
      env:
       - name: NAMESPACE_SCOPED_ARGO_ROLLOUTS
         value: 'false' 1
       - name: CLUSTER_SCOPED_ARGO_ROLLOUTS_NAMESPACES
         value: <list_of_namespaces_in_the_cluster-scoped_Argo_CD_instances> 2
    ...

   1

   Specify this value to enable or disable the cluster-scoped installation. If the value is set to 'false', it means that the you have enabled cluster-scoped installation. If it is set to 'true', it means that you have enabled namespace-scoped installation. If the value is empty, it is set to false.

   2

   Specifies a comma-separated list of namespaces that can host a cluster-scoped Argo Rollouts instance, for example test-123-cluster-scoped,test-456-cluster-scoped.

4. Click Save and Reload.