docs: rename canaryAnalysis to analysis

2026-04-15 06:57:34 +00:00 · 2020-02-28 13:24:09 +02:00
parent 98ecae93e1
commit a9fba0a1f2
18 changed files with 48 additions and 48 deletions
--- a/docs/gitbook/faq.md
+++ b/docs/gitbook/faq.md
@@ -232,7 +232,7 @@ Flagger measures the request success rate and duration using Prometheus queries.
 Spec:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
    - name: request-success-rate
      # minimum req success rate (non 5xx responses)
@@ -294,7 +294,7 @@ sum(
 Spec:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
    - name: request-duration
      # maximum req duration P99
--- a/docs/gitbook/how-it-works.md
+++ b/docs/gitbook/how-it-works.md
@@ -22,7 +22,7 @@ spec:
    name: podinfo
  service:
    port: 9898
-  canaryAnalysis:
+  analysis:
    interval: 1m
    threshold: 10
    maxWeight: 50
@@ -249,7 +249,7 @@ The canary analysis defines:
 Spec:

 ```yaml
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval:
    # max number of failed metric checks before rollback
--- a/docs/gitbook/tutorials/appmesh-progressive-delivery.md
+++ b/docs/gitbook/tutorials/appmesh-progressive-delivery.md
@@ -92,7 +92,7 @@ spec:
      perTryTimeout: 5s
      retryOn: "gateway-error,client-error,stream-error"
  # define the canary analysis timing and KPIs
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # max number of failed metric checks before rollback
@@ -329,7 +329,7 @@ Besides weighted routing, Flagger can be configured to route traffic to the cana
 Edit the canary analysis, remove the max/step weight and add the match conditions and iterations:

 ```yaml
-  canaryAnalysis:
+  analysis:
    interval: 1m
    threshold: 5
    iterations: 10
--- a/docs/gitbook/tutorials/contour-progressive-delivery.md
+++ b/docs/gitbook/tutorials/contour-progressive-delivery.md
@@ -91,7 +91,7 @@ spec:
      attempts: 3
      perTryTimeout: 5s
  # define the canary analysis timing and KPIs
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 30s
    # max number of failed metric checks before rollback
@@ -332,7 +332,7 @@ Besides weighted routing, Flagger can be configured to route traffic to the cana
 Edit the canary analysis, remove the max/step weight and add the match conditions and iterations:

 ```yaml
-canaryAnalysis:
+analysis:
  interval: 1m
  threshold: 5
  iterations: 10
--- a/docs/gitbook/tutorials/crossover-progressive-delivery.md
+++ b/docs/gitbook/tutorials/crossover-progressive-delivery.md
@@ -109,7 +109,7 @@ spec:
    # container port number or name (optional)
    targetPort: 9898
  # define the canary analysis timing and KPIs
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # max number of failed metric checks before rollback
--- a/docs/gitbook/tutorials/flagger-smi-istio.md
+++ b/docs/gitbook/tutorials/flagger-smi-istio.md
@@ -134,7 +134,7 @@ spec:
    # Istio virtual service host names (optional)
    hosts:
    - app.example.com
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 10s
    # max number of failed metric checks before rollback
--- a/docs/gitbook/tutorials/gloo-progressive-delivery.md
+++ b/docs/gitbook/tutorials/gloo-progressive-delivery.md
@@ -113,7 +113,7 @@ spec:
    port: 9898
    # container port number or name (optional)
    targetPort: 9898
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 10s
    # max number of failed metric checks before rollback
@@ -299,7 +299,7 @@ The demo app is instrumented with Prometheus so you can create a custom check th
 Edit the canary analysis and add the following metric:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
    - name: "404s percentage"
      threshold: 5
--- a/docs/gitbook/tutorials/istio-ab-testing.md
+++ b/docs/gitbook/tutorials/istio-ab-testing.md
@@ -63,7 +63,7 @@ spec:
      tls:
        # use ISTIO_MUTUAL when mTLS is enabled
        mode: DISABLE
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # total number of iterations
--- a/docs/gitbook/tutorials/istio-progressive-delivery.md
+++ b/docs/gitbook/tutorials/istio-progressive-delivery.md
@@ -70,7 +70,7 @@ spec:
      attempts: 3
      perTryTimeout: 1s
      retryOn: "gateway-error,connect-failure,refused-stream"
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # max number of failed metric checks before rollback
@@ -266,7 +266,7 @@ metadata:
  name: podinfo
  namespace: test
 spec:
-  canaryAnalysis:
+  analysis:
    # schedule interval
    interval: 1m
    # max number of failed metric checks before rollback
--- a/docs/gitbook/tutorials/kubernetes-blue-green.md
+++ b/docs/gitbook/tutorials/kubernetes-blue-green.md
@@ -93,7 +93,7 @@ spec:
  service:
    port: 9898
    portDiscovery: true
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 30s
    # max number of failed checks before rollback
@@ -258,7 +258,7 @@ The analysis can be extended with Prometheus queries. The demo app is instrument
 Edit the canary analysis and add the following metric:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
    - name: "404s percentage"
      threshold: 5
@@ -333,7 +333,7 @@ When deployed the Helm tester API will be available at `http://flagger-helmteste
 Add a helm test pre-rollout hook to your chart:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "conformance testing"
        type: pre-rollout
--- a/docs/gitbook/tutorials/linkerd-progressive-delivery.md
+++ b/docs/gitbook/tutorials/linkerd-progressive-delivery.md
@@ -68,7 +68,7 @@ spec:
    port: 9898
    # container port number or name (optional)
    targetPort: 9898
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 30s
    # max number of failed metric checks before rollback
@@ -256,7 +256,7 @@ The canary analysis can be extended with Prometheus queries.
 Let's a define a check for not found errors. Edit the canary analysis and add the following metric:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
    - name: "404s percentage"
      threshold: 3
@@ -389,7 +389,7 @@ spec:
  service:
    # container port
    port: 9898
-  canaryAnalysis:
+  analysis:
    interval: 1m
    threshold: 10
    iterations: 10
--- a/docs/gitbook/tutorials/nginx-progressive-delivery.md
+++ b/docs/gitbook/tutorials/nginx-progressive-delivery.md
@@ -126,7 +126,7 @@ spec:
    port: 80
    # container port number or name
    targetPort: 9898
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 10s
    # max number of failed metric checks before rollback
@@ -291,7 +291,7 @@ The demo app is instrumented with Prometheus so you can create a custom check th
 Edit the canary analysis and add the following metric:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
    - name: "latency"
      threshold: 0.5
@@ -353,7 +353,7 @@ Besides weighted routing, Flagger can be configured to route traffic to the cana
 Edit the canary analysis, remove the max/step weight and add the match conditions and iterations:

 ```yaml
-  canaryAnalysis:
+  analysis:
    interval: 1m
    threshold: 10
    iterations: 10
--- a/docs/gitbook/usage/alerting.md
+++ b/docs/gitbook/usage/alerting.md
@@ -85,7 +85,7 @@ the address in the secret will take precedence over the **address** field in the
 The canary analysis can have a list of alerts, each alert referencing an alert provider:

 ```yaml
-  canaryAnalysis:
+  analysis:
    alerts:
      - name: "on-call Slack"
        severity: error
--- a/docs/gitbook/usage/deployment-strategies.md
+++ b/docs/gitbook/usage/deployment-strategies.md
@@ -32,7 +32,7 @@ The canary analysis runs periodically until it reaches the maximum traffic weigh
 Spec:

 ```yaml
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # max number of failed metric checks before rollback
@@ -122,7 +122,7 @@ If Flagger finds a HTTP match condition, it will ignore the `maxWeight` and `ste
 Istio example:

 ```yaml
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # total number of iterations
@@ -155,7 +155,7 @@ interval * threshold
 App Mesh example:

 ```yaml
-  canaryAnalysis:
+  analysis:
    interval: 1m
    threshold: 10
    iterations: 2
@@ -170,7 +170,7 @@ Note that App Mesh supports a single condition.
 Contour example:

 ```yaml
-  canaryAnalysis:
+  analysis:
    interval: 1m
    threshold: 10
    iterations: 2
@@ -185,7 +185,7 @@ Note that Contour does not support regex, you can use prefix, suffix or exact.
 NGINX example:

 ```yaml
-  canaryAnalysis:
+  analysis:
    interval: 1m
    threshold: 10
    iterations: 2
@@ -217,7 +217,7 @@ with Kubernetes L4 networking. When using Istio you have the option to mirror tr
 You can use the blue/green deployment strategy by replacing `stepWeight/maxWeight` with `iterations` in the `canaryAnalysis` spec:

 ```yaml
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # total number of iterations
@@ -268,7 +268,7 @@ To use mirroring, set `spec.canaryAnalysis.mirror` to `true`.
 Istio example:

 ```yaml
-  canaryAnalysis:
+  analysis:
    # schedule interval (default 60s)
    interval: 1m
    # total number of iterations
--- a/docs/gitbook/usage/metrics.md
+++ b/docs/gitbook/usage/metrics.md
@@ -10,7 +10,7 @@ the release will be automatically rolled back with minimum impact to end-users.
 Flagger comes with two builtin metric checks: HTTP request success rate and duration.

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
    - name: request-success-rate
      interval: 1m
@@ -63,7 +63,7 @@ The following variables are available in query templates:
 A canary analysis metric can reference a template with `templateRef`:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
      - name: "my metric"
        templateRef:
@@ -122,7 +122,7 @@ spec:
 Reference the template in the canary analysis:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
      - name: "404s percentage"
        templateRef:
@@ -223,7 +223,7 @@ spec:
 Reference the template in the canary analysis:

 ```yaml
-  canaryAnalysis:
+  analysis:
    metrics:
      - name: "404s percentage"
        templateRef:
--- a/docs/gitbook/usage/monitoring.md
+++ b/docs/gitbook/usage/monitoring.md
@@ -84,7 +84,7 @@ Example:
 The event webhook can be overwritten at canary level with:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "send to Slack"
        type: event
--- a/docs/gitbook/usage/webhooks.md
+++ b/docs/gitbook/usage/webhooks.md
@@ -25,7 +25,7 @@ every action that Flagger takes during a canary deployment will be sent as JSON
 Spec:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "start gate"
        type: confirm-rollout
@@ -251,7 +251,7 @@ When deployed the Helm tester API will be available at `http://flagger-helmteste
 Now you can add pre-rollout webhooks to the canary analysis spec:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "smoke test"
        type: pre-rollout
@@ -268,7 +268,7 @@ If the helm test fails, Flagger will retry until the analysis threshold is reach
 If you are using Helm v3, you'll have to create a dedicated service account and add the release namespace to the test command:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "smoke test"
        type: pre-rollout
@@ -282,7 +282,7 @@ If you are using Helm v3, you'll have to create a dedicated service account and
 As an alternative to Helm you can use the [Bash Automated Testing System](https://github.com/bats-core/bats-core) to run your tests. 

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "acceptance tests"
        type: pre-rollout
@@ -308,7 +308,7 @@ will shift all traffic back to the primary instance and fail the canary.
 Manual gating with Flagger's tester:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "gate"
        type: confirm-rollout
@@ -322,7 +322,7 @@ If you have notifications enabled, Flagger will post a message to Slack or MS Te
 Change the URL to `/gate/approve` to start the canary analysis:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "gate"
        type: confirm-rollout
@@ -332,7 +332,7 @@ Change the URL to `/gate/approve` to start the canary analysis:
 Manual gating can be driven with Flagger's tester API. Set the confirmation URL to `/gate/check`:

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "ask for confirmation"
        type: confirm-rollout
@@ -366,7 +366,7 @@ The `confirm-promotion` hook type can be used to manually approve the canary pro
 While the promotion is paused, Flagger will continue to run the metrics checks and load tests.

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "promotion gate"
        type: confirm-promotion
@@ -377,7 +377,7 @@ The `rollback` hook type can be used to manually rollback the canary promotion.
 with Flagger's tester API by setting the rollback URL to `/rollback/check`  

 ```yaml
-  canaryAnalysis:
+  analysis:
    webhooks:
      - name: "rollback"
        type: rollback