feat(infra): gemini credential plumbing, behind enable_gemini - #1709
Merged
Conversation
Everything a gemini-model agent run needs, gated on one flag: the lore-gemini-api-key GSM container, the GEMINI_API_KEY entry in agent-secrets, and the gemini model family in the central cluster-agent's catalog render. The three ride the same var deliberately — listing a family whose key the Secret does not hold renders pods that die CreateContainerConfigError, so the map entry and the key must move together. The subsystem side needs nothing: gemini-* models already route to the GeminiAgent adapter running @google/gemini-cli (subsystem v0.10.x), and the CLI reads the standard GEMINI_API_KEY env the render mounts. The key is created IN the GCP project (gcloud services api-keys, restricted to the Generative Language API) so usage bills to the project — commands in docs/managing-secrets.md, lore-gemini-api-key added to seed-secrets' OPTIONAL list. No secret material anywhere in this diff. With the flag off — the default, and the example tfvars value — nothing changes: gemini recipes keep being refused with the reason on the /agents Rollout column, and dispatch keeps falling back to the org default (#1707). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
Lore is reviewing this PR — c131b023-11f0-4893-a991-1fa2f2b144a8. Reply to any review comment to discuss or approve a fix (e.g. "ok, fix it"). Comment |
🔍 Lore Spec ImpactExamined 7 changed file(s): 0 had graph data (no coupling found), 7 had none — no ingested test run covers them, so this check cannot speak for them. Deterministic · graph @ |
Contributor
|
Lore code-review run failed (failed — node "review" failed: Station or AgentDefinition not found — Unrecognized failure — see the Event Timeline metadata and agent pod logs.) — c131b023-11f0-4893-a991-1fa2f2b144a8. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything a gemini-model agent run needs, behind one
enable_geminiflag: thelore-gemini-api-keyGSM container (secrets.tf), theGEMINI_API_KEYentry inagent-secrets(ai-agents.tf), and thegeminimodel family in the central cluster-agent's catalog render (lore-platform.tf). The three ride the same variable deliberately — listing a family whose key the Secret does not hold would render pods that dieCreateContainerConfigErroron their secretKeyRef, so the map entry and the key must move together or not at all.The subsystem side needs nothing: I verified in ai-agent-subsystem (v0.10.x) that
gemini-*models already route to theGeminiAgentadapter running the official@google/gemini-cli, installed per run, and that the CLI reads the standardGEMINI_API_KEYenv — exactly the key the catalog render mounts for gemini-family models.The key itself is created in the GCP project via
gcloud services api-keys, restricted to the Generative Language API, so usage bills to the project and no console visit is needed — the commands are indocs/managing-secrets.md, andlore-gemini-api-keyjoinsseed-secrets.sh's OPTIONAL list. No secret material appears anywhere in this diff.With the flag off — the default, and what
terraform.tfvars.exampleships — nothing changes anywhere: gemini recipes keep being refused with the reason visible on the/agentsRollout column, and dispatch keeps falling back to the org default per #1707.Operator runbook after merge (also in the doc):
terraform apply, run the threegcloudcommands to create and seed the key, then re-save each gemini-model definition on/agents— a refusal is acked past permanently, so the re-save is what emits the catalog event that makes the sync loop re-render and apply the CRs.Verified:
terraform validateclean, both chart render checks pass, repo lint zero.🤖 Generated with Claude Code