run_639feaea8d1f28eb

input

{
  "request": "Triage Jira ticket MZCLD-3651: MozCloud tenant workgroup semantics can be confusing",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3651"
  ],
  "sourceContext": {
    "issue": "MZCLD-3651"
  }
}

summary

MZCLD-3651 is a backlog carry-over from OPST-2528 describing an architectural gap in global-platform-admin (g-p-a): there is no single explicit source of truth for tenant-to-workgroup mappings, so a tenant's Kubernetes-access workgroup and its GCP project-access workgroup can silently diverge (this happened for the remote-settings tenant). Prior work (MZCLD-1262) improved tooling but did not fix the root cause, and a metadata audit found six workgroups referenced by tenants that don't actually exist (content-sig-chains, meao, mfouterbounds, pocket-snowplow, probe-scraper, vpn-network-benchmark). The ticket has 0 comments and is still in Backlog with three concrete remaining scope items: (1) decide whether k8s-access and project-access workgroups should ever legitimately differ, (2) promote `workgroup` to a first-class g-p-a tenant metadata field instead of an `extra_attribute` override, and (3) audit/enforce consistency between g-p-a config and actual tenant project workgroup config. No linked Confluence runbook/design doc was found in the description to cross-reference.

findings

• Ticket is a migrated backlog item (from OPST-2528) capturing unresolved architecture/design work, not a live incident — appropriate for Backlog status, but currently has zero comments/triage activity despite clear, actionable scope.
• Root cause is architectural: g-p-a lacks an explicit, authoritative field for tenant workgroup ownership, relying instead on an 'extra_attribute' override, which allows k8s-access and GCP-project-access workgroup assignments to drift independently.
• A prior remediation (MZCLD-1262) addressed tooling but explicitly did not solve the underlying single-source-of-truth problem, meaning this ticket represents the still-outstanding design fix.
• A data-quality/integrity issue was already identified during the prior audit: several workgroups referenced in tenant metadata do not exist as actual workgroups, and a fix PR was planned but its status/completion is not documented in this ticket.
• No Confluence runbook or design doc link is present in the ticket description or comments to pull additional context from; all context comes from the OPST-2528 discussion history, which is not accessible via this ticket alone.
• Remaining scope is well-defined and splits into a design decision plus two implementation/audit tasks, suggesting this ticket could be broken into sub-tasks or refined with acceptance criteria before prioritization.

proposed actions

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3651"
    },
    "result": {
      "key": "MZCLD-3651",
      "summary": "MozCloud tenant workgroup semantics can be confusing",
      "status": "Backlog",
      "description_text": "Migrated from OPST-2528 as part of OPST backlog cleanup. Full discussion history is in that ticket. Problem:  There is no single explicit source of truth for tenant-to-workgroup mappings in global-platform-admin. This makes it hard to reason about which workgroup owns a tenant's Kubernetes access versus its GCP project-level access, and the two can drift (the remote-settings tenant was the motivating example: GCP project ownership moved to workgroup:syseng while k8s access stayed on workgroup:remote-settings). Work already done (in OPST-2528): MZCLD-1262 improved workgroup-related tooling but did not resolve the underlying single-source-of-truth problem. An audit found workgroups referenced in tenant metadata that don't actually exist: content-sig-chains, meao, mfouterbounds, pocket-snowplow, probe-scraper, vpn-network-benchmark. A fix PR was planned to correct these. Remaining scope: Determine whether workgroups for tenant k8s access should ever legitimately differ from workgroups for tenant project access. Make  workgroup  an explicit first-class field in g-p-a tenant metadata instead of relying on an  extra_attribute  override. Audit existing infra for consistency between g-p-a config and actual tenant project workgroup config, and decide whether to enforce a strict single source of truth.",
      "comment_count": 0,
      "comments": []
    }
  }
]

log