-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
added scripts and readme for manual testing (#11)
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
- Loading branch information
1 parent
348fcc2
commit 577b559
Showing
19 changed files
with
16,496 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,53 @@ | ||
# Usage | ||
This is for building and testing argo rollout integrations with Consul. For simplicity, everything uses the `make` command. The current version of these manual steps requires a custom build image of the argo controller included in the `install.yaml` file in this directory. Once required changes are made to the argo controller and released, these steps will be updated. | ||
|
||
# Prerequisites | ||
1. Kind is installed on the machine | ||
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 | ||
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. | ||
- 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 | ||
- You should see 100% of traffic directed to v1 | ||
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. | ||
- 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 | ||
- service-resolver: when finished, only has a stable filter (`Service.Meta.version=2`) | ||
|
||
# Verify Abort Behavior | ||
1. Run `Verify v1 to v2 rollout` steps 1-5 | ||
2. Run `make abort` to abort the rollout | ||
- splitting-watch: You should see traffic revert to entirely to v1 | ||
- rollout-watch: You should see the v2 image still exists in a bad state | ||
3. Run `make retry` to retry the 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 | ||
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 | ||
|
||
# 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) | ||
- 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 | ||
|
||
|
Oops, something went wrong.