feat(oabctl): extract ProvisionDriver trait for the write path (K8s driver slice 3a) - #98
Open
brettchien wants to merge 2 commits into
Open
feat(oabctl): extract ProvisionDriver trait for the write path (K8s driver slice 3a)#98brettchien wants to merge 2 commits into
brettchien wants to merge 2 commits into
Conversation
…river slice 3a) studio_api's write path (provision/scale/delete) called ECS-specific code (apply_manifests, ecsctl::scale_service, delete::run_with_bucket) directly, with no trait boundary — ADR-2's "RuntimeDriver is the only layer with vendor terms" only held for state classification, not CRUD. Introduce ProvisionDriver and an EcsDriver impl that thin-wraps the existing free functions unchanged, and route studio_api's write path through it. No behavior change: EcsDriver's methods are pass-throughs, all 85 existing oabctl tests stay green. This gives K8s driver (slice 3b, studio#97) a real seam with an actual caller to dispatch through, instead of a speculative trait with no consumer. Ref: studio#97 (K8s driver — ADR #63 slice 3, sub-slice tracking)
…ename ecs_service_name Found while starting K8sDriver (slice 3b): ProvisionDriver::apply took apply::ApplyOptions directly (an ECS-shaped type — 'cluster' field documented as "ECS cluster name or ARN"), and scale/delete took `cluster: &str` as a per-call parameter. Neither generalizes to a k8s driver, which has no "cluster" — it has a context+namespace bound at driver-construction time, same as EcsDriver already binds aws_config. - EcsDriver now holds `cluster` as an instance field alongside aws_config, matching how it already holds the AWS credential/region context. - New ProvisionOptions carries only what's actually generic (bucket, wait); apply::ApplyOptions (still ECS-specific, used directly by apply_manifests) is unchanged. - AppliedService.ecs_service_name -> resource_name: the only field crossing the trait boundary that still had a vendor-specific name. ServiceTarget (ECS-internal error detail, never crosses the trait) keeps its ECS name — it's genuinely ECS-only, not a leak. No behavior change for the ECS path; 85/85 tests green. This was going to bite immediately on K8sDriver's first method — fixing it now, before #98 merges, is cheaper than a second breaking change to studio_api after.
Contributor
Author
|
Pushed a follow-up commit: found while starting 3b that |
This was referenced Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ProvisionDrivertrait sostudio_api's write path (provision/scale/delete) no longer calls ECS-specific code directly.EcsDriveris the first (and today, only) implementation.EcsDriver's methods are thin pass-throughs to the existingapply::apply_manifests,ecsctl::scale::scale_service, anddelete::run_with_bucket— no logic moved or rewritten.Why route through the trait now, with only one impl?
manifest::Runtime::Kuberneteshas sat as a validated-but-rejected schema stub since slice-0 (both here and upstream inopenab/operator) — precedent in this codebase for declaring a seam before the second side exists. Same reasoning here, but scoped tighter:EcsDriveris actually wired intostudio_api's real call path (not dead code sitting unused), so slice 3b'sK8sDriverhas a genuine dispatch point to add itself to, instead of a speculative trait nothing calls.Scope note
This covers the write path only (
provision/scale/delete, the exact surfacestudio-cpdepends on — verified viagrep oabctl:: crates/studio-cp). Out of scope for 3a, tracked separately in #97:status.rs/studio_api.rsread-model functions (service_status/instance_status) — no driver branching yet, needs a k8s-observe counterpart.create.rs's interactive wizard — AWS-coupled from step 3 (Secrets Manager), before runtime is even chosen at step 4.Testing
cargo build -p oabctl/cargo test -p oabctl(85 tests) /cargo clippy -p oabctl --all-targets— all clean.cargo build --workspace --all-targetsCI gate locally — this environment has a hard 21GB disk ceiling and the workspace's aws-sdk dependency tree exceeded it mid-build (No space left on device, not a code error — CI's own comment already documents "aws-sdk-ec2 exceeds small boxes' RAM" as a known constraint). My change is additive-only tooabctl's public API (newpub mod driver+ two re-exports; no existing signature changed), so downstream crates (studio-cp,oab-mcp) shouldn't be affected, but flagging this so CI is the one that actually confirms it rather than my say-so.Ref #97.