feat(sdl): auto-match confidential compute deployments to capable providers - #3387
feat(sdl): auto-match confidential compute deployments to capable providers#3387baktun14 wants to merge 1 commit into
Conversation
…viders Derive the placement's TEE type from services' params.tee and inject a tee/type provider-matching requirement into the generated SDL's placement attributes, so only TEE-capable providers can bid/match. Strip it back out on import (mirroring location-region) so it stays out of the manual attribute editor and cannot duplicate across an import/export round-trip; the value is re-derived from params.tee on every export. Once present on the group spec, both on-chain bidding and the marketplace bid-screening request pick it up automatically.
📝 WalkthroughWalkthroughThis PR adds automatic derivation of a placement-level ChangesTEE type placement attribute
Estimated code review effort: 2 (Simple) | ~12 minutes Possibly related PRs
Suggested reviewers: ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3387 +/- ##
==========================================
- Coverage 69.79% 68.43% -1.37%
==========================================
Files 1100 1010 -90
Lines 26910 24577 -2333
Branches 6448 5990 -458
==========================================
- Hits 18783 16819 -1964
+ Misses 7133 6796 -337
+ Partials 994 962 -32
*This pull request uses carry forward flags. Click here to find out more.
🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
apps/deploy-web/src/utils/sdl/sdlGenerator.spec.ts (1)
67-105: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winGood coverage, but missing a conflicting-TEE-in-shared-placement test.
The dedup test (line 95-105) only exercises two services with the same
params.teevalue. There's no test locking down behavior when two services share a placement but declare different TEE types — which is exactly the scenario thesdlGenerator.tsmap-building logic (line 36-38) silently resolves via last-write-wins. Adding a test here would pin down intended behavior once/if that logic is hardened.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/deploy-web/src/utils/sdl/sdlGenerator.spec.ts` around lines 67 - 105, Add a regression test in sdlGenerator.spec.ts for two services sharing the same placement but declaring different params.tee values, since generateSdl currently builds the placement attributes in a way that can be overwritten by last-write-wins behavior. Use buildFormValues, buildLogCollectorService, and generateSdl to assert the intended outcome for conflicting tee/type inputs in the shared dcloud placement, so the behavior is explicitly pinned down alongside the existing tee/type merge and dedup tests.apps/deploy-web/src/utils/sdl/sdlGenerator.ts (1)
32-39: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winUnvalidated cross-service TEE consistency invariant.
This map silently uses last-write-wins if two services sharing a
placementIdset differentparams.teevalues, relying entirely on the comment's claim that "CON-449 guarantees" consistency. Unlike the unknown-placementIdcheck a few lines down (line 82-84) that throws, there's no equivalent guard here — if the invariant is ever violated (e.g., a future UI change, a bug in the placement-assignment flow, or a manually-crafted form state), the mismatch is silently discarded rather than surfaced.Consider adding a lightweight validation (e.g., detect a differing existing value in the map and throw/log) to fail loudly instead of silently picking one TEE type.
🛡️ Proposed defensive check
const teeTypeByPlacementId = new Map<string, TeeType>(); formValues.services.forEach(service => { - if (service.params?.tee) teeTypeByPlacementId.set(service.placementId, service.params.tee); + if (service.params?.tee) { + const existing = teeTypeByPlacementId.get(service.placementId); + if (existing && existing !== service.params.tee) { + throw new Error(`Placement "${service.placementId}" has services with conflicting TEE types: "${existing}" and "${service.params.tee}"`); + } + teeTypeByPlacementId.set(service.placementId, service.params.tee); + } });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/deploy-web/src/utils/sdl/sdlGenerator.ts` around lines 32 - 39, The teeTypeByPlacementId map in sdlGenerator.ts currently does last-write-wins when multiple services with the same placementId have different params.tee values, so add a defensive consistency check in the service iteration to detect an existing tee type mismatch and fail loudly instead of silently overwriting it. Update the logic around teeTypeByPlacementId population to compare each service's params.tee against any already stored value for that placementId and throw or log an explicit validation error if they differ, using the sdlGenerator flow and placement-based grouping as the reference point.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@apps/deploy-web/src/utils/sdl/sdlGenerator.spec.ts`:
- Around line 67-105: Add a regression test in sdlGenerator.spec.ts for two
services sharing the same placement but declaring different params.tee values,
since generateSdl currently builds the placement attributes in a way that can be
overwritten by last-write-wins behavior. Use buildFormValues,
buildLogCollectorService, and generateSdl to assert the intended outcome for
conflicting tee/type inputs in the shared dcloud placement, so the behavior is
explicitly pinned down alongside the existing tee/type merge and dedup tests.
In `@apps/deploy-web/src/utils/sdl/sdlGenerator.ts`:
- Around line 32-39: The teeTypeByPlacementId map in sdlGenerator.ts currently
does last-write-wins when multiple services with the same placementId have
different params.tee values, so add a defensive consistency check in the service
iteration to detect an existing tee type mismatch and fail loudly instead of
silently overwriting it. Update the logic around teeTypeByPlacementId population
to compare each service's params.tee against any already stored value for that
placementId and throw or log an explicit validation error if they differ, using
the sdlGenerator flow and placement-based grouping as the reference point.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 63c39702-54c1-4ebe-b782-1eaec9b90885
📒 Files selected for processing (4)
apps/deploy-web/src/utils/sdl/sdlGenerator.spec.tsapps/deploy-web/src/utils/sdl/sdlGenerator.tsapps/deploy-web/src/utils/sdl/sdlImport.spec.tsapps/deploy-web/src/utils/sdl/sdlImport.ts
|
Closing as redundant. chain-sdk 1.0.0-alpha.38 (already pinned in this repo) auto-injects the |
1 participant
Why
Part of CON-543.
When a tenant enables Confidential Compute (TEE) on a deployment, it must only ever be offered to providers that can actually run it. Today the per-service
params.teechoice only lands in the provider manifest (TEEParams) — it never becomes an on-chain group placement requirement, so any provider can bid on a confidential workload and a won bid can't be honored as confidential.@akashnetwork/chain-sdk'sgenerateManifestbuildsgroup_spec.requirements.attributesexclusively fromprofiles.placement.<name>.attributes; it does not derive anything fromparams.tee. So the builder must inject the matching requirement itself.What
Auto-manage a
tee/typeprovider-matching requirement derived from the tenant's TEE choice, fully round-tripped and hidden from the manual attribute editor.sdlGenerator.ts): derive each placement's TEE type from its services'params.tee(CON-449 guarantees one shared type per placement) and mergetee/type: cpu | cpu-gpuinto the placement attributes — mirroring the existinglocation-regionhandling.sdlImport.ts): droptee/typeinhydratePlacement(same lift aslocation-region) so it never populates the hand-editable attribute list and can't duplicate on re-export. The value is re-derived fromparams.tee(which already round-trips) on every export.Single injection point covers both consumers: once
tee/typeis on the group spec, on-chain bidding and the marketplace bid-screening request (buildPlacementScreeningRequest) both pick it up automatically. Non-TEE deployments are unchanged.Acceptance criteria
akash-network/console-air) with its own copy of these utils, so the same pattern must be mirrored there as a follow-up.Verification
sdlGenerator.spec.ts/sdlImport.spec.tscover injection (cpu/cpu-gpu), no-injection when off, merge with region + other attributes, single attribute for multi-service placements, import-drop, and no-duplication on re-import. Full affected SDL suite: 75 passing.generateManifest: a generated TEE SDL yieldsgroup requirements.attributes: [{"key":"tee/type","value":"cpu-gpu"}].Note (to confirm with provider/AEP-83): matching key is
tee/typewith valuecpu/cpu-gpu— the contract the console read side (confidentialCompute.ts) already uses. Only the constant changes if the provider expects a different key.Summary by CodeRabbit
New Features
Bug Fixes