What happened?
A ModelDeployment that omits spec.template.spec.engines[].members[].template.spec passes admission, because neither the ModelDeployment nor the ModelReplica XRD marks it required. compose-model-replica then asserts on it:
|
# The XRD types template.spec as optional, but a member with no spec |
|
# defines no pod to serve, so reaching here without one is malformed. |
|
assert member.template.spec is not None |
The AssertionError surfaces as a composition-function failure with a stack trace rather than a condition naming the field, so a user gets no indication of what's wrong with their manifest. The comment concedes the mismatch instead of the API enforcing it.
The same assert is at base.py#L333, and the pod-template equivalent at native.py#L96. #406 adds a Grove backend that copies the pattern, so it's worth fixing before more backends inherit it.
Adding required: [spec] to the member template in both XRDs makes this an admission error naming the field, and makes the asserts true by construction, like the leader/worker ones a CEL rule already guarantees. It does tighten the API: a manifest accepted today would be rejected, though today it only gets as far as crashing.
How can we reproduce it?
- Apply a
ModelDeployment whose engine member has template: {} (no spec), with everything else valid.
- The XR is admitted, and the
ModelReplica's composition fails on the assert above.
What environment did it happen in?
Modelplane version: main (0f42957b)
What happened?
A
ModelDeploymentthat omitsspec.template.spec.engines[].members[].template.specpasses admission, because neither the ModelDeployment nor the ModelReplica XRD marks itrequired. compose-model-replica then asserts on it:modelplane/functions/compose-model-replica/function/backends/llmd.py
Lines 127 to 129 in 0f42957
The
AssertionErrorsurfaces as a composition-function failure with a stack trace rather than a condition naming the field, so a user gets no indication of what's wrong with their manifest. The comment concedes the mismatch instead of the API enforcing it.The same assert is at
base.py#L333, and the pod-template equivalent atnative.py#L96. #406 adds a Grove backend that copies the pattern, so it's worth fixing before more backends inherit it.Adding
required: [spec]to the member template in both XRDs makes this an admission error naming the field, and makes the asserts true by construction, like theleader/workerones a CEL rule already guarantees. It does tighten the API: a manifest accepted today would be rejected, though today it only gets as far as crashing.How can we reproduce it?
ModelDeploymentwhose engine member hastemplate: {}(nospec), with everything else valid.ModelReplica's composition fails on the assert above.What environment did it happen in?
Modelplane version: main (
0f42957b)