# Default Analysis Templates

The chart ships built-in Argo Rollouts `AnalysisTemplate`s under
`rolloutAnalysisTemplates.defaultTemplates.basicTemplates.templates` — one `AnalysisTemplate` resource
per entry. They act as quality gates: while a rollout progresses, each template measures a signal and
**fails the rollout (triggering rollback)** when its condition is breached.

Three templates are provided — **all backed by Coralogix**:

| Template | Source | What it checks |
|----------|--------|----------------|
| `cpuUsageTemplate` | Coralogix | canary CPU vs stable (regression) |
| `memoryUsageTemplate` | Coralogix | canary memory vs stable (regression) |
| `coralogixAlertsTemplate` | Coralogix | any **active Coralogix case** for this service + namespace |

CPU/memory use Argo's `prometheus` metric provider against the `basicTemplates.promServerAddress`
PromQL endpoint (default `https://api.us1.coralogix.com/metrics`). The alerts gate is different: it
uses the `web` provider to **POST to the Coralogix Cases API** (`coralogixAlertsTemplate.promServerAddress`
+ `casesApiPath`, default `https://api.us1.coralogix.com/mgmt/openapi/5/cases/cases/v1`) — same host as
the metrics endpoint, different API path.

> Rendering a template doesn't run it — you reference it by its `name` from the rollout's
> `backgroundAnalysis`/steps (see [Steps & background analysis](steps-and-background-analysis.md)).

### Template names

Each template has a `name` (default `jfrog-cpu-usage-analysis` / `jfrog-memory-usage-analysis` /
`jfrog-coralogix-alerts`) — that exact string is what you reference under
`backgroundAnalysis.analysis.templates`. If several services share a namespace, **set a
service-specific `name` on each** so the `AnalysisTemplate` resources don't collide (e.g.
`my-svc-cpu-usage`). Whatever you set is what you reference — there's no auto-derivation to predict.

> **Required for `coralogixAlertsTemplate`:** its `name` **must end with `-coralogix-alerts`**
> (e.g. `my-svc-coralogix-alerts`). Prizm keys off this suffix to present the AnalysisTemplate in
> the UI, so the chart **fails the render** if the name doesn't match.

## Recommended setup (copy-paste)

Best practice: enable all three gates, give each a **service-specific `name`** (so multiple services in
a namespace don't collide), and reference those same names in `backgroundAnalysis`. The `name`s you set
are exactly what you reference — no derivation to predict. Replace `my-svc`:

```yaml
rolloutAnalysisTemplates:
  enabled: true
  authToken: "<coralogix-promql-token>"            # shared Bearer token
  defaultTemplates:
    basicTemplates:
      enabled: true                                 # turns on CPU + memory
      templates:
        cpuUsageTemplate:
          name: my-svc-cpu-usage
        memoryUsageTemplate:
          name: my-svc-memory-usage
        coralogixAlertsTemplate:
          name: my-svc-coralogix-alerts

rolloutStrategy:
  canary:
    backgroundAnalysis:
      analysis:
        templates:
          - templateName: my-svc-cpu-usage
          - templateName: my-svc-memory-usage
          - templateName: my-svc-coralogix-alerts
        startingStep: 1
```

That's the whole thing: the three templates run as background analysis for the rollout, and any of them
breaching rolls it back.

## Coralogix gate only (disable CPU/memory)

To run **only** the Coralogix active-cases gate and turn the CPU/memory checks off, keep the CPU/memory
group default off (`basicTemplates.enabled: false`) and switch the alerts gate on with its **own**
`enabled: true` (a per-template `enabled` overrides the group default). Then reference **only** the
alerts template in `backgroundAnalysis`:

```yaml
rolloutAnalysisTemplates:
  enabled: true                                 # master switch (must be on)
  authToken: "<coralogix-token>"                # shared Bearer token
  defaultTemplates:
    basicTemplates:
      enabled: false                            # CPU + memory stay OFF (they inherit this)
      templates:
        coralogixAlertsTemplate:
          enabled: true                         # opt in JUST the alerts gate
          name: my-svc-coralogix-alerts

rolloutStrategy:
  canary:
    backgroundAnalysis:
      analysis:
        templates:
          - templateName: my-svc-coralogix-alerts   # only the alerts gate
        startingStep: 1
```

Because CPU/memory omit their own `enabled`, they follow `basicTemplates.enabled: false` and are never
rendered — so the CPU/memory `AnalysisTemplate`s aren't created and nothing references them. Only the
Coralogix gate runs, failing the rollout while any active case exists for this service + namespace.

## Enabling & the inherit/override model

```yaml
rolloutAnalysisTemplates:
  enabled: true                 # master switch for ALL analysis templates
  authToken: "<coralogix-token>"  # shared Bearer token for the Coralogix PromQL endpoint
  defaultTemplates:
    basicTemplates:
      enabled: true             # group default for cpu/memory
      promServerAddress: "https://api.us1.coralogix.com/metrics"  # group default endpoint
      templates:
        cpuUsageTemplate: { ... }
        memoryUsageTemplate: { ... }
        coralogixAlertsTemplate: { ... }
```

Two group-level defaults can be **inherited or overridden per template**:

- **`enabled`** — by default all three templates omit their own `enabled` and inherit
  `basicTemplates.enabled`, so it toggles them together. Set a per-template `enabled` to override —
  e.g. `coralogixAlertsTemplate.enabled: true` with `basicTemplates.enabled: false` runs just the
  alerts gate without cpu/memory. The master `rolloutAnalysisTemplates.enabled` gates everything.
- **`promServerAddress`** — the Coralogix endpoint each template queries; a template may set its own
  to point at a different host (the alerts gate often does).

Auth is shared: when `rolloutAnalysisTemplates.authToken` is set, the chart renders a `*-prom-auth`
Secret and injects it as the `prom-auth-token` arg (`Authorization: Bearer …`).

## CPU & Memory templates

```yaml
cpuUsageTemplate:
  name: "jfrog-cpu-usage-analysis"
  interval: 10s
  changeMax: 1.25      # canary may be up to 25% above stable
  failureLimit: 3
  count: 0
```

| Param | Meaning |
|-------|---------|
| `name` | AnalysisTemplate resource name (referenced from the rollout). |
| `interval` | How often the metric is sampled. |
| `changeMax` | Max allowed canary/stable ratio. `successCondition: result[0] <= changeMax`; exceed → fail. |
| `failureLimit` | Consecutive failed measurements tolerated before the analysis aborts the rollout. |
| `count` | Number of runs; `0` = run continuously for the whole rollout (background analysis). |

These use the prometheus provider against `promServerAddress` and compare canary metrics to the
stable version, so a deployment that meaningfully degrades CPU/memory is rolled back.

## Coralogix active-cases gate

`coralogixAlertsTemplate` fails the rollout while Coralogix has any **active case** for the current
service and namespace.

```yaml
coralogixAlertsTemplate:
  # enabled:                       # omit to inherit basicTemplates.enabled; set true/false to override
  name: "jfrog-coralogix-alerts"   # must end with "-coralogix-alerts" (enforced; Prizm UI keys off it)
  promServerAddress: "https://api.us1.coralogix.com"       # Cases API host
  casesApiPath: "/mgmt/openapi/5/cases/cases/v1"           # appended to promServerAddress
  interval: 60s
  failureLimit: 3
  count: 0
  successCondition: "len(result) == 0"   # no active cases -> pass
  failureCondition: "len(result) > 0"     # any active case -> rollback
  statuses:                               # case statuses treated as firing
    - CASE_STATUS_ACTIVE
  serviceLabelKey: serviceName            # filters.labels[].key
  namespaceGroupingKey: kubernetes.namespace  # filters.groupings[].key
  responseJsonPath: "{$.cases}"           # array node the gate counts
```

**How it works**
- It uses the **web provider** to **POST** to the Coralogix Cases API (`<promServerAddress><casesApiPath>`).
- The request body filters **entirely server-side** — namespace, service, and status:
  ```json
  {"filters":{"groupings":[{"key":"kubernetes.namespace","values":["<.Release.Namespace>"]}],
              "labels":[{"key":"serviceName","values":["<service>"]}],
              "statuses":["CASE_STATUS_ACTIVE"]}}
  ```
- **Service value** = `canaryServiceName` with any `mt_` prefix stripped (e.g. `mt_event` → `event`),
  matching the Coralogix `serviceName` label. **Namespace** = `.Release.Namespace`. Neither is re-entered.
- Because the filtering is server-side, the response contains only this service's active cases in this
  namespace. The gate reads the cases array via `jsonPath: {$.cases}` and evaluates `len(result)`:
  empty → pass; one-or-more active cases → fail/rollback. No client-side filtering is needed.

**Auth:** the shared `authToken` is sent as `Authorization: Bearer …` (same Secret as cpu/memory);
`Content-Type: application/json` is set automatically.

**Tuning**
- `statuses` — case statuses treated as firing (default `["CASE_STATUS_ACTIVE"]`).
- `serviceLabelKey` / `namespaceGroupingKey` — the Cases API filter keys (defaults `serviceName` /
  `kubernetes.namespace`).
- `responseJsonPath` — the array node the gate counts (default `{$.cases}`).
- Endpoint: per-template `promServerAddress` + `casesApiPath` (host falls back to
  `basicTemplates.promServerAddress` if unset).
