You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e4d6cc8
Browse filesBrowse the repository at this point in the historyBrowse files
fix(instance-preferences): run integ tests in CI, reject managed spot client-side, stabilize IntPipeVar codegen (#6250)
* fix(instance-preferences): reject managed spot client-side; make IntPipeVar codegen-stable
The documentation lists managed spot training among the settings that are
mutually exclusive with instance_preferences, but the client-side
validator only checked instance_type, instance_groups and
instance_placement_config, so the spot conflict surfaced as a service
error. Both validator copies now reject an explicit
enable_managed_spot_training=True; False and unset remain valid.
The IntPipeVar annotation on the five instance-preferences count members
was a hand edit that generate_shapes could not reproduce: only
ResourceConfig.InstanceCount was registered in PIPE_VAR_OVERRIDES, so the
next regeneration would have narrowed the others back to Optional[int].
All five are registered, and a unit test asserts the extractor emits
IntPipeVar for each so a dropped override fails loudly.
* test(instance-preferences): run integ tests in the standard CI account
Both integ tests were gated on account-specific environment variables
that no CI configuration sets, so every CI run skipped them and the suite
passed without exercising the feature.
Training coverage:
- tests/integ/train/shallow: two accepted cases (uniform and
per-preference counts; submit, Describe echo, stop) and four rejected
cases (instance_type, managed spot and duplicate types client-side; the
five-entry cap server-side). Runs on every pull request.
- tests/integ/train/test_instance_preferences.py: a CPU-only end-to-end
test that submits a job with a preference list and follows it until the
service selects a winner and the job completes on it, asserting the
winner is one of the submitted types and the top-level type stays unset.
It stops the job in a finally block so it never runs to max_runtime on
shared quota.
The processing test uses the suite's SageMakerRole and resolves its image
through image_uris, as the other sagemaker-core integration tests do, and
now stops the job in a finally block once the winner is observed.
Candidate types remain overridable via *_TEST_INSTANCE_TYPES for accounts
whose default types lack quota; no account-specific values remain.
Verified in us-west-2: all six shallow cases pass, the training e2e runs
to Completed on a selected winner, and the processing test passes with a
resolved winner.
0 commit comments