agent-substrate / agent-substrate/substrate

Add Helm charts for installing Agent Substrate

Abierto
#79 8 comentarios 0 reacciones 0 asignados Ver en GitHub
area/dev-infra kind/feature prio/P1
Lenguaje dominante
Go
Estrellas
1.8k
Forks
316
Merge medio
2 d 43 min
PR fusionados (30 d)
287

Descripción

Agent Substrate is currently installed through `hack/install-
ate.sh` / `hack/install-ate-kind.sh`, which apply raw
manifests, run `ko`, generate prerequisite secrets, and handle
Kind/GKE-specific differences.

We should add Helm-based installation with two charts:

- `agent-substrate-crds`: installs only Agent Substrate CRDs.
- `agent-substrate`: installs the runtime/control-plane
system.

Splitting CRDs into their own chart follows current Helm
operational best practice: CRDs are cluster-scoped, upgrade-
sensitive, and often managed by cluster/platform admins
separately from namespaced workloads.

## Proposed Chart Layout

```text
charts/
agent-substrate-crds/
Chart.yaml
crds/
ate.dev_actortemplates.yaml
ate.dev_workerpools.yaml
README.md

agent-substrate/
Chart.yaml
values.yaml
templates/
README.md
```

## Motivation

A Helm-based install would make it easier to:

- Install Agent Substrate without relying on repo-local shell
scripts.
- Support GitOps tooling such as Argo CD and Flux.
- Manage CRDs independently from runtime workloads.
- Configure images, ValKey, TLS, storage, and observability
through values.yaml.
- Provide clearer install, upgrade, and uninstall workflows.

## Scope

### agent-substrate-crds

This chart should install:

- WorkerPool CRD
- ActorTemplate CRD
- Any future ate.dev CRDs

Acceptance criteria:

- helm install agent-substrate-crds ./charts/agent-substrate-
crds
- CRDs are installed using Helm’s crds/ convention.
- Chart README documents CRD upgrade behavior and uninstall
caveats.
- Runtime chart does not template or own CRDs directly.

### agent-substrate

This chart should install the core system components:

- ate-api-server
- ate-controller
- atelet
- atenet-router
- atenet-dns
- ValKey, optionally
- podcertificate-controller
- RBAC, ServiceAccounts, Services, ConfigMaps, Secrets, and
projected volumes

The runtime chart should assume CRDs are already installed and
document installing agent-substrate-crds first.

## Configuration Requirements

Expose values for:

- Component images, tags, pull policies.
- Internal vs external ValKey.
- Redis/ValKey TLS and auth settings.
- GCS/S3/local storage backend settings.
- Kind/local development profile.
- GKE/cloud profile.
- OTLP and Prometheus configuration.
- Existing secret names for session JWT/CA pools and pod
certificate CAs.

## Bootstrap Secret Handling

The current install script generates prerequisite secrets such
as:

- session-id-jwt-pool
- session-id-ca-pool
- service-dns-ca-pool
- pod-identity-ca-pool
- valkey-ca-certs
- ate-api-server-envvars

The chart should document whether these are:

1. Provided by the user before install.
2. Generated by Helm hooks or bootstrap Jobs.
3. Supported through both modes.

Externally supplied secrets should likely be the production/
default path.

## Acceptance Criteria

- helm install agent-substrate-crds ./charts/agent-substrate-
crds installs CRDs.
- helm install agent-substrate ./charts/agent-substrate -n
ate-system --create-namespace installs the core system after
CRDs exist.
- helm uninstall agent-substrate -n ate-system removes runtime
resources cleanly without deleting CRDs.
- Runtime chart fails clearly or documents behavior when CRDs
are missing.
- values.yaml covers current hack/install-ate.sh
configuration.
- Kind/local and cloud/GKE install paths are documented.
- CI validates helm lint and helm template for both charts.
- Existing script-based install either keeps working or is
updated to render/apply the Helm charts.

## Non-Goals

- Packaging demo apps into the core runtime chart.
- Solving production-grade certificate/key rotation in the
first version.
- Removing the existing development scripts immediately.

## Implementation Notes

Current install logic lives in:

- hack/install-ate.sh
- hack/install-ate-kind.sh
- manifests/ate-install/
- manifests/ate-install/generated/
- manifests/ate-install/kind/

The current manifests use ko:// image references. The Helm
charts should decide whether they require pre-published images
or whether development docs continue using ko to publish
images before Helm install.

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.