agentplat▸control runs deployments agents metering + agent
← runs

run_d1e75791bca529d7

SUCCEEDED retrigger →
jira-triage v1 · jira-triage-k8s · owner ingest:jira-new-ticket (api) · via jira-new-ticket · cloud-engineering

input

{
  "request": "Triage Jira ticket MZCLD-3773: MozCloud Helm charts: Gateway API health check protocol is hardcoded to HTTP (no TCP support)",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3773"
  ],
  "sourceContext": {
    "issue": "MZCLD-3773"
  }
}

summary

MZCLD-3773 is a well-documented, actionable Backlog ticket describing a real gap in the MozCloud application Helm chart: Gateway API HealthCheckPolicy protocol is hardcoded to HTTP, even though the underlying mozcloud-gateway-lib and HealthCheckPolicy CRD already support TCP (and the mapping logic for it). The reporter has done root-cause analysis down to specific file/line references and proposed a concrete fix. This is called out as a blocker for FxA's migration to the MozCloud chart (MZCLD-2323), since FxA's internal-otel-collector currently relies on a bespoke chart with TCP health-check support to work around a port-exposure limitation on the NEG. No comments exist yet and status is still Backlog, so it needs prioritization/triage. No linked Confluence runbook/design doc was referenced in the ticket, so none was pulled. Recommend acknowledging the analysis, confirming ownership/priority, and linking explicitly to the FxA migration blocker so it gets scheduled ahead of MZCLD-2323.

findings

  • Root cause identified precisely: templates/gateway/backend.yaml hardcodes protocol: HTTP on the host-options path (line ~134) and omits protocol entirely on the backends path (lines 65-83), falling back to the library default of HTTP in _helpers.tpl (lines 433-436).
  • The underlying library (mozcloud-gateway-lib) is already protocol-agnostic and supports TCP via a protocol->property mapping; the application chart simply never exposes a way to select it.
  • values.schema.json has a related but incompatible field: hosts.<host>.options.healthCheck.type exists for the Ingress API (GCLB health checks) but is explicitly documented as Ingress-only and rejected for api: gateway via allOf cross-field validation; there is no gateway-specific protocol key at all.
  • This is a stated blocker for FxA's migration to the MozCloud chart (MZCLD-2323). FxA's internal-otel-collector needs a TCP health check on port 8080 because its HTTP health endpoint (port 13133) isn't exposed on the NEG; this only works today via FxA's bespoke chart's custom gateway-healthcheckpolicy.yaml supporting healthCheck.protocol.
  • A clear, scoped fix is already proposed by the reporter, reducing the effort needed for triage/implementation: add hosts.<host>.options.healthCheck.protocol (enum HTTP|TCP, possibly HTTPS) scoped to api: gateway, wire it into backend.yaml on both code paths, and consider unifying naming with the existing Ingress healthCheck.type field.
  • Ticket has zero comments and remains in Backlog status despite being flagged as a migration blocker; it has not been triaged/prioritized yet, and related tickets (MZCLD-2323, MZCLD-3567, MZCLD-3638, MZCLD-3322) provide context but were not accessible to this run for cross-checking current status.

proposed actions

none

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3773"
    },
    "result": {
      "key": "MZCLD-3773",
      "summary": "MozCloud Helm charts: Gateway API health check protocol is hardcoded to HTTP (no TCP support)",
      "status": "Backlog",
      "description_text": "Problem The MozCloud application chart hardcodes  protocol: HTTP  for Gateway API health checks, so a tenant cannot configure a TCP health check even though the  HealthCheckPolicy  CRD and the  mozcloud-gateway  library both support one. mozcloud/application/templates/gateway/backend.yaml:134  emits  protocol: HTTP  unconditionally on the host-options code path. On the  backends  code path (lines 65-83)  protocol  is never set at all, so it falls through to the library default in  mozcloud-gateway-lib.defaults.healthCheckPolicy.config  ( _helpers.tpl:433-436 ), which is also  http . The library itself is protocol-agnostic.  mozcloud-gateway-lib.defaults.healthCheckPolicy.protocolProperty  ( _helpers.tpl:438-441 ) maps: HTTP: httpHealthCheck\nTCP: tcpHealthCheck and  _healthcheckpolicy.yaml  renders  config.type: {{ $config.protocol }}  with the matching property block. TCP support therefore exists in the library and is simply unreachable from the application chart. The schema compounds this.  hosts.<host>.options.healthCheck.type  exists in  values.schema.json , but it is documented \"Protocol used by the GCLB health check (Ingress API only)\" and is actively rejected for  api: gateway  by the  allOf  cross-field validation. There is no  protocol  key at all. Impact FxA needs this. Its  internal-otel-collector  host runs a  TCP  health check on port 8080 as a deliberate workaround: the collector serves HTTP health checks on port 13133, but that port is not exposed on the NEG, so an HTTP health check cannot be used. This works today because FxA's bespoke chart has its own  gateway-healthcheckpolicy.yaml  that supports  healthCheck.protocol . Once FxA moves to the MozCloud chart (MZCLD-2323) the configuration cannot be expressed, so this is a blocker for that migration. Proposed approach Add  hosts.<host>.options.healthCheck.protocol  to  values.schema.json  with enum  HTTP | TCP  (plus  HTTPS  if the library adds the mapping), scoped to  api: gateway . Read it in  templates/gateway/backend.yaml  instead of hardcoding  protocol: HTTP , on both the host-options and  backends  code paths. Consider unifying  options.healthCheck.type  (Ingress) and the new gateway key under one name, so there aren't two spellings for the same concept. Related:  MZCLD-3322 (ingress-path  options.healthCheck  passthrough, Done), MZCLD-3638 (non-functional internal host type), MZCLD-2323 (FxA MozCloud chart migration), MZCLD-3567 (FxA Ingress to Gateway API migration).",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-2323"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-2323"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3567"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3567"
      }
    },
    "blocked": true
  }
]

usage

{
  "model": "claude-sonnet-5",
  "input_tokens": 7069,
  "output_tokens": 2391,
  "estimated_cost_usd": 0.057072
}

approvals

[]

log

launched k8s job run-run-d1e75791bca529d7 in ns/mzcld-demo-dev image=us-docker.pkg.dev/moz-fx-mzcld-demo-prod/mzcld-demo-prod/agentplat:latest
runner started
live reasoning model=claude-sonnet-5
POLICY: blocked read jira.issue.read args={'key': 'MZCLD-2323'} not in run subject
POLICY: blocked read jira.issue.read args={'key': 'MZCLD-3567'} not in run subject