{
"request": "Triage Jira ticket MZCLD-3835: Document the ArgoCD architecture and deployment model in the ArgoCD Admin Guide",
"references": [
"https://mozilla-hub.atlassian.net/browse/MZCLD-3835"
],
"sourceContext": {
"issue": "MZCLD-3835"
}
}MZCLD-3835 is a documentation task (currently in Backlog, no comments) requesting a new architecture/deployment-model section for the ArgoCD Admin Guide. The description is very well-scoped and detailed, effectively acting as its own outline/spec for the work, covering seven concrete sub-topics (instance/permission domains, self-management via app-of-apps, tenant ApplicationSet generation path, two-stage Helm/Go-template rendering, Terraform-provisioned infra, supply chain/secrets handling, and break-glass procedures). No runbook or Confluence doc is linked directly in the ticket, so no additional Confluence context was pulled. This looks ready to be picked up as-is; triage should confirm ownership/priority and clarify a couple of open scoping questions the author already flagged (e.g., whether DR content needs its own follow-up ticket).
Triage note: This is a well-scoped documentation task ready to be worked — the description already outlines 7 concrete sections to add (permission-domain instances, self-management/app-of-apps circularity, tenant ApplicationSet fan-out, two-stage Helm/Go-template rendering, Terraform-provided infra, supply chain & manually-created secrets, break-glass procedures). Suggest: (1) assign an owner and set a priority/target sprint since it's still in Backlog; (2) confirm scope decision up front on the 'Data, backup, and disaster recovery' section — per the ticket, keep it short (stating ArgoCD holds no durable state beyond Redis cache and Git) or split it into a separate ticket if it needs real investigation; (3) link the actual ArgoCD Admin Guide Confluence page ID/URL on this ticket for easier reviewer access; (4) as noted in the description, keep directory/template-level structural detail in the argo/ READMEs and link out to them rather than duplicating, to avoid staleness.
[
{
"capability": "jira.issue.read",
"args": {
"key": "MZCLD-3835"
},
"result": {
"key": "MZCLD-3835",
"summary": "Document the ArgoCD architecture and deployment model in the ArgoCD Admin Guide",
"status": "Backlog",
"description_text": "Problem The ArgoCD Admin Guide covers access, per-instance URLs and log links, upgrade testing, and CLI/RBAC recipes, but never explains how ArgoCD is actually deployed. The closest it comes is one line per instance: \"ArgoCD does manage its own internal application\". That leaves the reader unable to answer basic questions during an incident, including what would have to be true for ArgoCD to be able to repair itself, and what to do when it cannot. Proposed work Add a section (or child page) to the Admin Guide covering the deployment model at a level that stays true as the code moves: Instances as permission domains. sandbox , webservices , dataservices , each in its own argocd-<domain> namespace on global-platform-admin-mgmt , each with its own values file, IAP backend, and OAuth client, and what that separation means when only one instance is broken. Self-management. The argo/k8s/argocd-bootstrap chart deploys the upstream argo-cd chart as a subchart, and the platform pieces (image updater, metrics UI extension, repository details, ephemeral access, rollouts, preview environments) are Applications rendered by that same chart. Explain the app-of-apps shape and the circularity: ArgoCD syncs the Application that manages ArgoCD. The tenant path. tenants/<app_code>.yaml feeds the ApplicationSet template, which generates one ApplicationSet per tenant, realm, region, and chart, which in turn generates the Applications. This is the piece most likely to be misread during an incident, and it explains why a single tenant file change can fan out widely. Two-stage templating, called out explicitly. Helm renders {{ \"{{\" }} .name {{ \"}}\" }} into a literal Go-template placeholder that the ApplicationSet controller evaluates later against its git generator. Show one before/after example so the reader stops trying to read it as a single pass. Terraform. What argo/tf provides (static IP, DNS, IAP-fronted backend, Cloud Armor policies, workload identity) and how it relates to the Kubernetes side. Supply chain and secrets. Charts are mirrored to GAR via relok8s ; several secrets (IAP OAuth, Dex service account, GitHub App credentials) are created by hand and are not in the chart. Break-glass. How to operate on ArgoCD directly with kubectl or helm install when it cannot manage itself, which the guide alludes to but never spells out. Notes Keep structural detail (which directory holds what, which template renders what) in the argo/ READMEs and link to them from here, rather than duplicating a listing that goes stale. This page should explain how it works and why it is shaped this way; GitHub stays authoritative for the specifics. Filling in the guide's currently empty \"Data, backup, and disaster recovery\" heading is in scope if the answer is short (ArgoCD holds no durable state of its own beyond Redis cache and Git). If it turns out to need real work, split it out.",
"comment_count": 0,
"comments": []
}
}
]{
"model": "claude-sonnet-5",
"input_tokens": 4055,
"output_tokens": 1701,
"estimated_cost_usd": 0.03768
}[]