Add Custom Agent

[jbouder]

• Added custom austin permits agent
• Updated chart for custom agent config and database connection

[viniciusdc]

Hey @jbouder, going to approve since @pmeier already weighed in, but flagging one structural thing for a possible follow-up.

The bit I'm uneasy about is backend/src/ravnar_nebari_chat/austin_permit_agent.py. That path makes the agent part of the published Python package, so every consumer of quay.io/nebari/nebari-chat-backend ends up shipping the Austin module and its psycopg/OpenRouter imports, even when enabled: false. The austinPermits.* block in values.schema.json has the same flavor: one tenant's DB shape lands in the chart's public contract.

The chat pack already has half the plumbing for a cleaner shape. config.inline is merged into the rendered Ravnar config so agent registration is already extensible without code changes, and the Dockerfile sets RAVNARPATH=/var/ravnar/plugins. What's missing is a generic way to deliver the plugin code itself. Something like a backend.extraPlugins value that renders a ConfigMap from filename to source and mounts it under RAVNARPATH. A deployment using it would look roughly:

# in the demo deployment, not here
backend:
  extraPlugins:
    austin_permit_agent.py: |
      # full file content
config:
  inline:
    agents:
      austin-permits:
        cls_or_fn: austin_permit_agent.create_agent
        params:
          api_key: ${OPENROUTER_API_KEY}
          # ...

austin_permit_agent.py and the demo values then live in the deployment repo and the pack stays generic.

One related thing: the current template renders apiKey and db.password straight into config.yaml, which ends up in a ConfigMap. Should those come in via envFrom from a Secret and get referenced as ${ENV_VAR} in the inline config instead?

Happy to open a follow-up issue once this lands so the pattern gets cleaned up before a second tenant agent shows up.

[viniciusdc]

Following up on my earlier suggestion to point ArgoCD at this branch directly. I was wrong, it doesn't work today.

Two things in the way:

helm/nebari-chat/Chart.yaml has version: "set-by-cd" and appVersion: "set-by-cd". Those are placeholders rewritten by .github/actions/patch-helm-chart only at release time, so a raw helm template against the branch fails validation with chart.metadata.version "set-by-cd" is invalid. That part is patchable locally.

The harder one is the images. .github/workflows/docker.yml gates both the Quay login and the push step behind if: github.event_name != 'pull_request', and the workflow only triggers tag pushes on v[0-9]+\.[0-9]+\.[0-9]+. So nothing built on a PR branch ever lands in Quay, which means even if I patch the chart version, the backend/frontend tags referenced by the rendered manifests don't exist in the registry. A third-party consumer (the NIC deployment in our case) has no image to pull.

So branch installs aren't really a thing here right now. To unblock the Austin Permits work I'll need either a pre-release tag cut from this branch, or a one-off image push from the PR build. Happy to push a dev tag if that's the simpler path.

[pmeier]

I don't share @viniciusdc comment re extra dependency. Adding a package to connect to Postgres is fine, since this is not the ravnar base.

[jbouder]

Note, i'm going to leave this here until after this weeks demos have completed

[pmeier]

Could you please add psycopg to the dependencies? We are currently pulling this implicitly with the serve extra in

nebari-chat-pack/backend/pyproject.toml

Line 23 in 7c61427

"ravnar[serve,pydantic-ai]==0.0.8",