agent-substrate / agent-substrate/substrate

Add Helm charts for installing Agent Substrate

Aberta
#79 8 comentários 0 reações 0 responsáveis Ver no GitHub
area/dev-infra kind/feature prio/P1
Linguagem predominante
Go
Estrelas
1.8k
Forks
316
Merge médio
2d 43min
PRs com merge (30d)
287

Descrição

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.

Guia de contribuição

Abrir o guia de contribuição

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.