Skip to content

Commit

Permalink
update steps for clarity
Browse files Browse the repository at this point in the history
Signed-off-by: Michael Wilkerson <[email protected]>
  • Loading branch information
wilkermichael committed Feb 7, 2024
1 parent 577b559 commit 7000dd5
Showing 1 changed file with 13 additions and 15 deletions.
28 changes: 13 additions & 15 deletions testing/README.MD
Original file line number Diff line number Diff line change
Expand Up @@ -6,24 +6,24 @@ This is for building and testing argo rollout integrations with Consul. For simp
2. Helm is installed on the machine
3. Kubectl is installed on the machine 5
4. Argo kubectl extension is installed on the machine
5. The plugin binary is in a directory on the machine
5. The plugin binary is in a directory on the machine
6. Update any of the necessary variables in the `Makefile` to match your environment

# Verify v1 to v2 rollout
1. Run `make setup` to setup the system with the static-server/client, consul and argo.
1. Run `make setup` to setup the system with the static-server/client, consul and argo.
- Everything is installed to the `default` namespace except for Argo gets installed in the `argo` namespace.
2. Run `make check-service-splitter` and `make check-service-resolver`
- service-splitter shows 100% of traffic directed to stable
- service-resolver only has a stable filter (`Service.Meta.version=1`)
3. Run `make rollout-watch` to watch the deployments
4. Run `make splitting-watch` to witness the traffic splitting between deployments
2. Run `make check-service-splitter` and `make check-service-resolver`, we will run these scripts periodically throughout the testing scenarios
- service-splitter: shows 100% of traffic directed to stable
- service-resolver: only has a stable filter (`Service.Meta.version=1`)
3. Open a new window and run `make rollout-watch` to watch the deployments. This will run continuously throughout the test.
4. Open a new window and run `make splitting-watch` to witness the traffic splitting between deployments. This will run continuously throughout the test.
- You should see 100% of traffic directed to v1
5. Run `make deploy-canary-v2` to deploy a canary rollout.
5. Run `make deploy-canary-v2` to deploy a canary rollout.
- splitting-watch: You should see traffic begin directing to V2 but most of the traffic is still directed to V1
- rollout-watch: You should see the rollout now includes a canary deployment for v2
- service-splitter: shows 80% of traffic directed to stable and 20% directed to canary
- service-resolver: includes a canary filter (`Service.Meta.version=2`)
6. Run `make promote` to promote the canary deployment and watch it succeed.
6. Run `make promote` to promote the canary deployment and watch it succeed.
- splitting-watch: You should see the traffic slowly shift to V2 until all traffic is directed to V2 and none to V1
- rollout-watch: You should see more v2 deployments until there are 5 v1 and 5 v2 deployments. After some time, you should see the v1 deployments scale down to 0
- service-splitter: slowly changes the percentages until canary is getting 100% of traffic. Finally, when finished shows 100% of traffic directed to stable
Expand All @@ -38,16 +38,14 @@ This is for building and testing argo rollout integrations with Consul. For simp
- splitting-watch: You should see traffic begin directing to V2 but most of the traffic is still directed to V1
- rollout-watch: You should see the rollout now includes a canary deployment for v2
4. Run `make promote` to promote the canary deployment and watch it succeed.
- splitting-watch: You should see the traffic slowly shift to V2 until all traffic is directed to V2 and none to V1
- rollout-watch: You should see more v2 deployments until there are 5 v1 and 5 v2 deployments. After some time, you should see the v1 deployments scale down to 0
- splitting-watch: You should see the traffic slowly shift to V2 until all traffic is directed to V2 and none to V1
- rollout-watch: You should see more v2 deployments until there are 5 v1 and 5 v2 deployments. After some time, you should see the v1 deployments scale down to 0

# Verify Undo Behavior
1. Run all steps for `Verify v1 to v2 rollouts`
2. Run `make undo`. This will begin a rollback to the previous version (v1)
2. Run `make undo`. This will begin a rollback to the previous version (v1)
- splitting-watch: You should see traffic begin directing to V2 but most of the traffic is still directed to V1
- rollout-watch: You should see the rollout now includes a canary deployment for v1
3. Run `make promote` to promote the canary deployment and watch it succeed.
- splitting-watch: You should see the traffic slowly shift to V1 until all traffic is directed to V1 and none to V2
- rollout-watch: You should see more v1 deployments until there are 5 v1 and 5 v2 deployments. After some time, you should see the v2 deployments scale down to 0


- rollout-watch: You should see more v1 deployments until there are 5 v1 and 5 v2 deployments. After some time, you should see the v2 deployments scale down to 0

0 comments on commit 7000dd5

Please sign in to comment.