From 7000dd50968568f27091b095bc5c87cc58715d8e Mon Sep 17 00:00:00 2001 From: Michael Wilkerson Date: Wed, 7 Feb 2024 11:52:58 -0800 Subject: [PATCH] update steps for clarity Signed-off-by: Michael Wilkerson --- testing/README.MD | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/testing/README.MD b/testing/README.MD index 542ec54..5be13e1 100644 --- a/testing/README.MD +++ b/testing/README.MD @@ -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 @@ -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 \ No newline at end of file