run_e8825e39f260b1d5

input

{
  "request": "Triage Jira ticket MZCLD-3646: Add valueFrom.secretKeyRef / configMapKeyRef (per-key env vars) support to MozCloud Helm charts",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3646"
  ],
  "sourceContext": {
    "issue": "MZCLD-3646"
  }
}

summary

MZCLD-3646 requests a new feature for the MozCloud Helm charts: support for `valueFrom.secretKeyRef` / `configMapKeyRef` style per-key environment variable injection on Deployments, Jobs, and CronJobs. Currently the chart only supports whole-secret injection via `envFrom.secretRef`, which forces env var names to match secret/configMap keys exactly. This breaks for keys that don't match desired env var names, and fails outright for keys containing dashes (invalid env var names), causing pods to silently start without required credentials. The ticket originated as a hard blocker discovered during the llm-proxy migration (MZCLD-2331) and has clear acceptance criteria. It is currently unestimated/untriaged in Backlog with no comments.

findings

• Root cause is a chart capability gap: only envFrom.secretRef (whole-secret import) is supported, with no per-key valueFrom.secretKeyRef/configMapKeyRef mechanism.
• Impact is functional/correctness, not just cosmetic: secret keys containing dashes are silently dropped by Kubernetes when using envFrom, meaning affected pods can start successfully but without required credentials — a silent failure mode.
• This is a known migration blocker: it was surfaced during the llm-proxy mozcloud migration (referenced ticket MZCLD-2331) and is explicitly called out as the hard blocker preventing that chart's Deployments/Jobs/CronJobs from migrating to mozcloud.
• Requirements are well-scoped with concrete acceptance criteria covering all three workload types (workloads, jobs, cronjobs), which should make implementation and review straightforward.
• Ticket is currently in Backlog with zero comments and no visible priority/estimate, despite being described as a hard blocker for an active migration — suggests it may need re-prioritization or linkage to the blocked migration ticket.

proposed actions

Triage note: This is a well-scoped chart enhancement request — add per-key env var injection (valueFrom.secretKeyRef / configMapKeyRef) to the mozcloud Helm chart's workload/job/cronjob templates, alongside the existing whole-secret envFrom.secretRef mechanism. Given this is called out as the hard blocker for the llm-proxy migration (MZCLD-2331), recommend prioritizing this out of Backlog and linking it explicitly as 'blocks' MZCLD-2331 if not already linked. Suggested implementation approach: extend the values schema to accept a list of extraEnv entries of the form {name, valueFrom: {secretKeyRef: {name, key}}} or {configMapKeyRef: {name, key}} per container, and render them into the container's `env:` list (in addition to/alongside the existing `envFrom` block). Also worth confirming whether keys with dashes should additionally be validated/rejected at the envFrom level so failures are loud rather than silent in the future. Please confirm priority/owner and target milestone so this can unblock the llm-proxy migration.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3646"
    },
    "result": {
      "key": "MZCLD-3646",
      "summary": "Add valueFrom.secretKeyRef / configMapKeyRef (per-key env vars) support to MozCloud Helm charts",
      "status": "Backlog",
      "description_text": "Context:  Surfaced during the  llm-proxy  mozcloud migration (MZCLD-2331). This is the hard blocker preventing that chart's Deployments/Jobs/CronJobs from migrating. Problem.  The mozcloud chart's only secret-injection mechanism is whole-secret  envFrom.secretRef , where the env-var name  equals  the key in the secret. It has no  valueFrom.secretKeyRef  /  configMapKeyRef  support anywhere. Many services map individual secret keys to differently-named env vars, e.g.: db-username  \u2192  DATABASE_USERNAME litellm-masterkey  \u2192  PROXY_MASTER_KEY together-ai-api-key  \u2192  TOGETHERAI_API_KEY With  envFrom  those env vars would instead be named literally  db-username  etc. Worse, keys containing  dashes  are invalid env-var names, so Kubernetes skips them entirely \u2192 pods start without credentials. Ask.  Support declaring env entries sourced from a specific secret/configMap key with an arbitrary env-var name (i.e.  valueFrom.secretKeyRef  /  configMapKeyRef ) on workloads, jobs, and cronjobs. Acceptance criteria.  A workload/job/cronjob can define an env var whose name differs from the source key, sourced from a named Secret or ConfigMap key; rendered manifest uses  valueFrom.secretKeyRef  /  configMapKeyRef .",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-2331"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-2331"
      }
    },
    "blocked": true
  }
]

log