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.
There was a problem hiding this comment.
Removed the ATEConfig in the update since it only contains the substrate control service's endpoint. This value is set in an env var in the manifest, and isn't supposed to be configured by users.
For now, the custom harnesses don't need it either. So removing from this PR.
| 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"
There was a problem hiding this comment.
Removed in the update.
| } | ||
|
|
||
| // ServerConfig configures the gRPC server. | ||
| type ServerConfig struct { |
There was a problem hiding this comment.
ServerConfig isn't a harness config, right?
There was a problem hiding this comment.
My plan is to add a new config package for the new harness path, similar to controller2. It'll be a clean package without the legacy structs from the old config.go.
It's a sibling package to the old config.go, and the build tag "harness" controls which package to use. So it includes the server side configs as well.
The harnessconfig is not a proper name for my intention. I've renamed the package to config2 in the update. Hope it clarifies things a bit.
| } | ||
|
|
||
| // 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"?
There was a problem hiding this comment.
I imagine it'll be an "antigravity" type harness, with its own ID. And there could be other antigravity harnesses with different IDs and configs in the future.
E.g., "antigravity_1" with coding tools, pro model; "antigravity_2" with search tools, flash model etc.
| 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.
There was a problem hiding this comment.
Discussed offline. Moved it to an env var.
| 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
|
|
||
| antigravity: | ||
| - id: antigravity-example | ||
| address: "localhost:50053" |
There was a problem hiding this comment.
We can set a default address:
- localhost:50053 on local deployments
- the ${ACTOR_ID}:50053 on Substrate.
There was a problem hiding this comment.
Yes, the address is optional. I'll update to just use the default in this example yaml.
| type HarnessesConfig struct { | ||
| // Default is the id of the harness to serve when a request specifies no harness. | ||
| Default string `yaml:"default,omitempty"` | ||
| Antigravity []AntigravityHarnessConfig `yaml:"antigravity,omitempty"` |
There was a problem hiding this comment.
why do we need a separate harness config for Antigravity?
3 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/config2package 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;config2in the-tags=harnessbuild.controller2toconfig2only: 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?"