updated splitting-watch script to now show the info for the service…

… splitter and service resolver

- No longer need to run the check splitter/resolver steps manually. Information is conveyed to the watch script

Signed-off-by: Michael Wilkerson <[email protected]>

.gitignore

@@ -1,4 +1,5 @@
 .vscode/
 .idea/
 rollouts-plugin-trafficrouter-consul
+consul
 testing/resources/kind_config.yaml

testing/README.MD

@@ -13,18 +13,17 @@ This is for building and testing argo rollout integrations with Consul. For simp
 # Verify v1 to v2 rollout
 1. Run `make setup` to setup the system with the static-server/client, consul and argo. This will also build the latest plugin.
    - 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`, we will run these scripts periodically throughout the testing scenarios
+2. Open a new window and run `make rollout-watch` to watch the deployments. This will run continuously throughout the test.
+3. Open a new window and run `make splitting-watch` to witness the traffic splitting between deployments. This will run continuously throughout the test and shows the splitting in realtime as well as the necessary sections from the `service-resolver` and `service-splitter`
+   - You should see 100% of traffic directed to v1
    - 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.
+4. 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.
+5. 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

testing/scripts/splitting-watch.sh

@@ -47,7 +47,14 @@ while true; do
     timestamp=$(date +"%Y-%m-%d %H:%M:%S")
 
     # Update the CI with the percentages and the timestamp
-    printf "\r$timestamp - Total: $total_count, V1: $v1_count req/$v1_percentage%%, V2: $v2_count req/$v2_percentage%%"
+    #koutput=$(kubectl describe servicesplitters.consul.hashicorp.com)
+    splitterOutput=$(kubectl get servicesplitters.consul.hashicorp.com -o yaml | yq e '.items[].spec.splits' - | yq '.')
+    resolverOutput=$(kubectl get serviceresolver.consul.hashicorp.com -o yaml | yq e '.items[].spec.subsets' - | yq '.')
+
+    clear
+    printf "service-splitter:\n%s\n\nservice-resolver:\n%s\n" "$splitterOutput" "$resolverOutput"
+    printf "\n"
+    printf "\r%s - Total: %d, V1: %d req/%d%%, V2: %d req/%d%%" "$timestamp" "$total_count" "$v1_count" "$v1_percentage" "$v2_count" "$v2_percentage"
 
     sleep 0.003
 done