run_370de227bd06f3da

input

{
  "request": "Triage Jira ticket MZCLD-3836: Document what each ArgoCD component does and map it to the Grafana dashboard",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3836"
  ],
  "sourceContext": {
    "issue": "MZCLD-3836"
  }
}

summary

MZCLD-3836 is a documentation task (currently in Backlog, no comments) asking for a canonical Confluence reference describing each ArgoCD component (argocd-server, application-controller, applicationset-controller, repo-server, redis, dex, notifications-controller, argocd-image-updater, argocd-ephemeral-access, argocd-repository-details/metrics UI extension, argo-rollouts), mapped to the existing Grafana dashboard rows (Overview, Application Status, Sync Stats, Controller Stats, Controller Telemetry, AppSet Controller Telemetry, Cluster Stats, Repo Server Stats, Server Stats, Redis Stats). The ticket also calls for adding short linked descriptions to dashboard rows/panels and explicitly flagging components with no current dashboard coverage. This work is a stated prerequisite for a related runbook effort and is linked to MZCLD-3140 (dashboard coverage gaps), which I was unable to read due to access policy restrictions on that resource.

findings

• Ticket is well-scoped documentation/observability work, not a bug — it defines a clear deliverable (Confluence component reference) and a clear secondary deliverable (dashboard annotation linking back to it).
• The ticket specifies a required content structure per component: purpose, user-visible failure symptom, namespace/workload, log location, and corresponding dashboard row — useful acceptance criteria for scoping the doc.
• Explicit dependency/sequencing risk: the reference doc is stated as a prerequisite ('should land before or with') for separate runbook work, and coverage gaps are deliberately deferred to MZCLD-3140.
• Could not verify current status/scope of the linked dependency MZCLD-3140 (dashboard coverage for notifications-controller, dex, image-updater, ephemeral-access, rollouts) — access to that issue was blocked by policy, so triage cannot confirm whether it's already in progress or blocking this work.
• No runbook or Confluence page ID was referenced in the ticket text itself, so the 'Admin Guide' location mentioned for the new reference could not be independently verified via confluence_page_read.

proposed actions

Triage notes:

This is a well-scoped docs task — no code change needed. Scope is clear: one Confluence page (alongside the Admin Guide) with a short section per ArgoCD component (argocd-server, application-controller, applicationset-controller, repo-server, redis, dex, notifications-controller, argocd-image-updater, argocd-ephemeral-access, argocd-repository-details/metrics UI extension, argo-rollouts), each covering: purpose, user-visible failure symptom, namespace/workload, log location, and the Grafana dashboard row it maps to. Then a follow-up pass to add a one-line description + link on each dashboard row/panel pointing back to its section.

A few things worth confirming before pulling this into a sprint:
1. Sequencing: the description notes this reference should land before or with the runbook work — is a runbook ticket already tracked/linked, and should this be blocked-by/blocks that ticket for visibility?
2. Dependency: components without current dashboard coverage (notifications-controller, dex, image-updater, ephemeral-access, rollouts) are explicitly called out as belonging to MZCLD-3140 for panel coverage — worth linking that ticket here (as 'relates to') and confirming its current status/priority so the two efforts stay coordinated.
3. Confirm which components have good upstream docs to link to directly (per the note to prefer linking upstream over paraphrasing) vs. which need original Mozilla-specific writeups — could speed up estimation.

Recommend moving to a near-term sprint given it unblocks the runbook effort and improves incident response (responders currently can't map dashboard panels like Workqueue Depth to actual user impact).

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3836"
    },
    "result": {
      "key": "MZCLD-3836",
      "summary": "Document what each ArgoCD component does and map it to the Grafana dashboard",
      "status": "Backlog",
      "description_text": "Problem The  ArgoCD dashboard  is already organized by component:  Overview ,  Application Status ,  Sync Stats ,  Controller Stats ,  Controller Telemetry ,  AppSet Controller Telemetry ,  Cluster Stats ,  Repo Server Stats ,  Server Stats ,  Redis Stats . That layout only helps someone who already knows what an application controller does versus a repo server. Nothing in our docs says which component serves the UI, which one talks to tenant clusters, which one renders Helm, or what a user notices when each one fails. So a responder looking at a spiking  Workqueue Depth  panel has no way to reason about impact. Proposed work Write one canonical component reference (Confluence, alongside the Admin Guide) with a short section per component we actually run: argocd-server  (API and UI, behind IAP) application-controller  (reconciles Applications against target clusters) applicationset-controller  (generates Applications from our ApplicationSets) repo-server  (clones repos, renders Helm) redis  (reconciliation cache) dex  (SSO, Google group lookup) notifications-controller  (Slack and Grafana annotations) argocd-image-updater argocd-ephemeral-access argocd-repository-details  and the metrics UI extension argo-rollouts Each section stays short and covers: what it does, the user-visible symptom when it is down or degraded, which namespace and workload it runs as, where its logs are, and which dashboard row covers it. Then make the dashboard point at it: Add a one-line description to each row or key panel explaining what the component does, with a link to its section in the reference. Blurbs stay concise deliberately; the dashboard should not become a third copy of the docs we have to keep in sync. Note in the reference which components have no dashboard coverage today (notifications controller, dex, image-updater, ephemeral-access, rollouts) so responders know the absence of a panel is not evidence of health. Adding that coverage belongs to  MZCLD-3140 . Notes Where upstream documents a component well, link to upstream rather than paraphrasing. The value we add is the Mozilla-specific part: which namespace, which realm, what our users see, which panel, and which log query. This reference is what the runbook links to for \"understand the component\", so it should land before or with the runbook work.",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3140"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3140"
      }
    },
    "blocked": true
  }
]

log