Add the scaffolding for harness config in controller v2.#48
Conversation
|
|
||
| // ATEConfig configures the substrate control plane endpoint used by | ||
| // substrate harnesses. | ||
| type ATEConfig struct { |
There was a problem hiding this comment.
I was envisioning this differently. User shouldn't know we have a different implementation on Agent Substrate for the built-in harnesses.
We check AX_SUBSTRATE environment variable, if it's "1", we behave differently when serving built-in harnesses like "antigravity".
We'd hardcode the built-in names.
If AX_SUBSTRATE=1 and harness is "antigravity", "claudecode", ...:
- resume the harness actor for conversation_id
- use HarnessService to communicate
- suspend on completion
We'd keep ATEConfig for custom harnesses.
| Server ServerConfig `yaml:"server"` | ||
| EventLog EventLogConfig `yaml:"eventlog"` | ||
| Harnesses HarnessesConfig `yaml:"harnesses,omitempty"` | ||
| ATE ATEConfig `yaml:"ate,omitempty"` |
There was a problem hiding this comment.
Should we rename this?
Substrate SubstrateConfig `yaml:"substrate,omitempty"
| } | ||
|
|
||
| // ServerConfig configures the gRPC server. | ||
| type ServerConfig struct { |
There was a problem hiding this comment.
ServerConfig isn't a harness config, right?
| } | ||
|
|
||
| // SQLiteConfig configures the SQLite event log file. | ||
| type SQLiteConfig struct { |
There was a problem hiding this comment.
Ditto. SQLiteConfig or EventLogConfig aren't harness configs.
| // AntigravityHarnessConfig registers an Antigravity harness, which connects to | ||
| // a gRPC server at a fixed address. | ||
| type AntigravityHarnessConfig struct { | ||
| ID string `yaml:"id"` // Unique harness identifier |
There was a problem hiding this comment.
Do we want AntigravityHarness to have a modifiable ID?
Shouldn't its ID always be "antigravity"?
| namespace: ax | ||
| data: | ||
| ax.yaml: | | ||
| ate: |
There was a problem hiding this comment.
Do we want to have an "ate" at the top level here? There are very few people on the earth that will have to override "api.ate-system.svc:443", e.g. Substrate developers. We may just use some environmental variables and consider this option when it's relevant.
| endpoint: "api.ate-system.svc:443" | ||
| harnesses: | ||
| default: hello-world | ||
| substrate: |
There was a problem hiding this comment.
Custom harnesses shouldn't be deployed to the ax namespace. ax namespace is for ax's own deployment.
The example should be something like:
substrate:
- id: hello-world
namespace: my-harness
template: my-harness-template
port: 50053
2 participants
Summary
This PR adds the scaffolding config for harness to complete controller2 path E2E. Clean up the legacy agent/planner from the controller2.
internal/config/harnessconfigpackage for the-tags=harnessbuild, kept separate from the default
configpackage (which retains planner/agent config).
cliutilexports the per build tag alias:configin the default build;harnessconfigin the-tags=harnessbuild.controller2to harnesses only: drop the unused agent registry(
RegisterLocal/Remote/Colab/ATE, agent maps), deleteregistry_ate.go.internal/ax2.yamlfor a local config example, andax-deployment2.yamlfor substrate example.Tested
python python/antigravity/harness_server.pygo run -tags=harness ./cmd/ax exec --config internal/ax2.yaml --input "What is the weather in New York?"