Repository navigation
refactor(deploy): expose ADX directly and streamline guides - #94
Conversation
Expose the HTTPS control and PTY listener and HTTP sandbox data listener through the ADX public Service. Remove the external proxy resources and migrate guided cloud profiles and SDK endpoint discovery to the direct Service while retaining ADX certificates and cloud load-balancer annotations. Replace proxy-specific routing checks with rendered Service contracts and real direct-ingress SDK coverage. Update deployment guides and architecture labels to match the deployed topology. Signed-off-by: robbluo <luo1442@gmail.com>
896170c to
365df85
Compare
365df85 to
ee7dd40
Compare
Keep runnable deployment, SDK, observability and workload instructions in the maintained guides. Remove dated cluster validation reports and benchmark baselines from the source tree, and replace historical test narratives and proposed pipelines with current fixtures, commands and result semantics. Retain the required runtime, storage, administrator and fault-injection prerequisites and audit expectations. Consolidate repeated operational details through guide links. Signed-off-by: robbluo <luo1442@gmail.com>
ee7dd40 to
18bc101
Compare
Add the official openJiuwen-ai/agent-dx repository under src/agent-dx and pin its gitlink to the commit resolved from v0.1.0rc1. Document the source reference while retaining the existing checksum-pinned binary release inputs. Signed-off-by: robbluo <luo1442@gmail.com>
rcyw
left a comment
rcyw
left a comment
There was a problem hiding this comment.
Reviewed the direct ADX ingress changes at 8ee0be5. The direct API/PTY/HTTP forwarding checks and both providers' configuration/rendering checks passed, but the reproducible migration issue below needs fixing before approval. Please fix the generated gateway configuration, update the migration examples, and add regression coverage for an existing shell environment. We will revalidate the fixed head and its CI before merging into develop.
Clear inherited AKERNEL_GATEWAY_ADDRESS for the default control and data ports while retaining explicit gateway exports for custom ports. Default SDK setup continues to require only the server address and API key. Remove the deprecated YR_GATEWAY_ADDRESS fallback and its test. Update migration instructions and remove the separate mocked print-env test in favor of existing SDK endpoint tests and direct ingress E2E coverage. Signed-off-by: robbluo <luo1442@gmail.com>
rcyw
left a comment
rcyw
left a comment
There was a problem hiding this comment.
Approved after revalidating fe32395. The stale inherited gateway migration issue is fixed; seven real environment-generation/source + SDK migration scenarios and 312 local SDK/benchmark-driver tests passed, together with lint, type and deployment syntax checks. All 10 validation checks on this head are green, including Standalone E2E. Checked-in migration regression coverage is a non-blocking follow-up, as clarified in the resolved review thread. Ready to merge into develop.
2 participants
Cloud deployment profiles currently place Traefik between the load balancer and ADX. This change exposes the ADX Ingress/API Server Pods directly through
akernel-adx-public: HTTPS API and PTY traffic defaults to port 443 → 8443, and HTTP sandbox traffic to port 80 → 8080. Both external ports are configurable; the existing SDK environment variables and ADX certificate/API-key Secret are retained.The change removes Traefik workloads, certificate options and routing-specific tests, updates both Terraform providers and guided configuration, and makes
make print-envdiscover the ADX Service. Standalone CI now covers real direct-ingress authentication, PTY and HTTP forwarding. The documentation retains current deployment, SDK and test instructions while removing seven dated validation/performance reports and historical test narratives.Validation
fmtandvalidateafter backend-disabled initialization.Deployment migration
Existing cloud profiles must replace retired ingress options with the documented
adx_*settings. Helm removes the old proxy resources during upgrade; the new Service may receive a different load-balancer address, which must be verified before switching clients. Cloud ELB provisioning and a Kubernetes rollout have not been performed for this change.