[ethnzhng]

Summary

Updates the DJL-LMI image config to the newly released LMI v30 (0.38.0-lmi30.0.0-cu130, DJL Serving 0.38.0 / vLLM 0.31.0) for SageMaker Python SDK 3.x (sagemaker-core). DJL Serving stays at 0.38.0, so this edits the 0.38.0 key in place and the registries map is unchanged.

Changes

• sagemaker-core/src/sagemaker/core/image_uri_config/djl-lmi.json: bump the 0.38.0 tag_prefix from 0.38.0-lmi29.0.0-cu130 to 0.38.0-lmi30.0.0-cu130
• sagemaker-core/tests/unit/image_uris/test_djl.py: remove the stale 0.38.0-lmi29.0.0-cu130 entry from KNOWN_MISSING_COMBINATIONS. No lmi30 entry is added: the 3.x 0.38.0 registries map already lists ap-east-2, so an exemption there would be a no-op.

Testing

• pytest tests/unit/image_uris/test_djl.py in sagemaker-core on the PR head: 8 passed on Python 3.10 and 3.12
• image_uris.retrieve("djl-lmi", region="us-west-2", version="0.38.0") and version="latest" both return 763104351884.dkr.ecr.us-west-2.amazonaws.com/djl-inference:0.38.0-lmi30.0.0-cu130; the 0.36.0 key still returns the lmi27 tag

[mohamedzeidan2021]

The tag bump itself looks right, but I think the two halves of this PR contradict each other and it's worth settling before merge.

On this branch, 0.38.0's registries map does contain ap-east-2 (975050140332). That has two consequences:

1. The new KNOWN_MISSING_COMBINATIONS entry is a no-op here. test_djl_lmi_config_for_framework_has_all_regions only asserts expected_regions - actual_regions == {}, so exempting a region that is already present in registries removes nothing from the expected set. The same is true of the existing "0.38.0-lmi29.0.0-cu130": {"ap-east-2"} entry on 3.x — it's inherited convention from 2.x, where it is load-bearing because 2.x's 0.38.0 has no ap-east-2 key at all.

2. The config and the test now assert opposite things. The config says an ap-east-2 caller should get 975050140332.dkr.ecr.ap-east-2.amazonaws.com/djl-inference:0.38.0-lmi30.0.0-cu130, while the test change declares that exact framework:tag:region combination doesn't exist in ECR. If the test's claim is the accurate one, then image_uris.retrieve("djl-lmi", region="ap-east-2", version="0.38.0") — and version="latest", since the alias points at 0.38.0 — returns a URI that fails at pull time instead of raising. The 2.x counterpart (feat: update SDK to use latest LMI v30 image for sdk v2.x #6484) is self-consistent on this point because it has no ap-east-2 registry entry to begin with.

So which is it?

• If lmi30 is published to ap-east-2: drop the KNOWN_MISSING_COMBINATIONS addition from this PR, since it documents a gap that doesn't exist (and arguably clean up the stale lmi29 key, which no version's tag_prefix matches anymore).
• If it isn't: ap-east-2 shouldn't be in the 3.x 0.38.0 registries map, or the bump should wait on ap-east-2 replication.

For reference, I checked the manifest directly (GET /v2/djl-inference/manifests/0.38.0-lmi30.0.0-cu130) and got HTTP 200 in every region I have an opted-in account for: us-east-1, us-west-2, eu-west-1, eu-west-2, eu-west-3, eu-central-1, eu-north-1, ca-central-1, ap-south-1, ap-northeast-1/2/3, ap-southeast-1/2. ap-east-2 is opt-in and I couldn't reach it, so I can't settle that one from outside — someone with access to the ap-east-2 DLC account would need to confirm.

Worth noting that PR Checks won't answer this either way: the DJL image-URI tests are static assertions over the same JSON they read, so nothing in CI verifies that a tag actually exists in ECR.

[github-actions]

🤖 AI code review

This PR bumps the DJL-LMI 0.38.0 image tag_prefix from lmi29.0.0-cu130 to lmi30.0.0-cu130 for sagemaker-core (SDK v3.x) and registers the new tag in the test KNOWN_MISSING_COMBINATIONS for ap-east-2. Since DJL Serving stays at 0.38.0, editing the existing version key in place (rather than adding a new key) is correct and matches the established pattern. The change is clean and consistent with prior LMI bump precedent (e.g. PR #6301, #5976).

_{Reviewed commit c55261e. Automated review; verify before acting.}

[ethnzhng]

The tag bump itself looks right, but I think the two halves of this PR contradict each other and it's worth settling before merge.

On this branch, 0.38.0's registries map does contain ap-east-2 (975050140332). That has two consequences:

1. **The new `KNOWN_MISSING_COMBINATIONS` entry is a no-op here.** `test_djl_lmi_config_for_framework_has_all_regions` only asserts `expected_regions - actual_regions == {}`, so exempting a region that is already present in `registries` removes nothing from the expected set. The same is true of the existing `"0.38.0-lmi29.0.0-cu130": {"ap-east-2"}` entry on 3.x — it's inherited convention from 2.x, where it _is_ load-bearing because 2.x's `0.38.0` has no `ap-east-2` key at all.

2. **The config and the test now assert opposite things.** The config says an `ap-east-2` caller should get `975050140332.dkr.ecr.ap-east-2.amazonaws.com/djl-inference:0.38.0-lmi30.0.0-cu130`, while the test change declares that exact `framework:tag:region` combination doesn't exist in ECR. If the test's claim is the accurate one, then `image_uris.retrieve("djl-lmi", region="ap-east-2", version="0.38.0")` — and `version="latest"`, since the alias points at `0.38.0` — returns a URI that fails at pull time instead of raising. The 2.x counterpart ([feat: update SDK to use latest LMI v30 image for sdk v2.x #6484](https://github.com/aws/sagemaker-python-sdk/pull/6484)) is self-consistent on this point because it has no `ap-east-2` registry entry to begin with.

So which is it?

* If `lmi30` **is** published to `ap-east-2`: drop the `KNOWN_MISSING_COMBINATIONS` addition from this PR, since it documents a gap that doesn't exist (and arguably clean up the stale `lmi29` key, which no version's `tag_prefix` matches anymore).

* If it **isn't**: `ap-east-2` shouldn't be in the 3.x `0.38.0` `registries` map, or the bump should wait on ap-east-2 replication.

For reference, I checked the manifest directly (GET /v2/djl-inference/manifests/0.38.0-lmi30.0.0-cu130) and got HTTP 200 in every region I have an opted-in account for: us-east-1, us-west-2, eu-west-1, eu-west-2, eu-west-3, eu-central-1, eu-north-1, ca-central-1, ap-south-1, ap-northeast-1/2/3, ap-southeast-1/2. ap-east-2 is opt-in and I couldn't reach it, so I can't settle that one from outside — someone with access to the ap-east-2 DLC account would need to confirm.

Worth noting that PR Checks won't answer this either way: the DJL image-URI tests are static assertions over the same JSON they read, so nothing in CI verifies that a tag actually exists in ECR.

The exemption was a no-op on 3.x, since the 0.38.0 registries map already has ap-east-2. Pushed a commit that drops the new lmi30 entry and the stale lmi29 entry from KNOWN_MISSING_COMBINATIONS; test_djl.py passes on Python 3.10 and 3.12.

On ap-east-2: lmi30 was released to the same region set as lmi29, which includes ap-east-2, and the release only completes once every region in that set succeeds. I haven't pulled the manifest from ap-east-2 directly since it is opt-in. If it turns out to be missing there, the fix is to remove ap-east-2 from the 0.38.0 registries rather than restore the exemption.

The 2.x PR (#6484) keeps its exemption because 2.x has no ap-east-2 key for 0.38.0.

[github-actions]

🤖 AI code review

This PR bumps the DJL-LMI 0.38.0 tag_prefix from lmi29 to lmi30 in sagemaker-core and removes the stale 0.38.0-lmi29.0.0-cu130 entry from KNOWN_MISSING_COMBINATIONS. The code change is correct and the resulting test state is self-consistent: ap-east-2 is present in the 0.38.0 registries map (line 47) and the test only checks for missing regions, so no lmi30 entry in KNOWN_MISSING_COMBINATIONS is needed or appropriate. Two concerns worth noting: the PR description claims it registers 0.38.0-lmi30.0.0-cu130 in KNOWN_MISSING_COMBINATIONS but the diff does not add it (description/diff mismatch), and the static tests do not verify the image is actually published in ap-east-2.

_{Reviewed commit 9f03ad7. Automated review; verify before acting.}

[github-actions]

🤖 AI code review

This PR bumps the DJL-LMI 0.38.0 tag_prefix from 0.38.0-lmi29.0.0-cu130 to 0.38.0-lmi30.0.0-cu130 in the sagemaker-core image config and removes the now-stale 0.38.0-lmi29.0.0-cu130 ap-east-2 entry from KNOWN_MISSING_COMBINATIONS. The change is consistent: the 0.38.0 registries map already lists ap-east-2 (975050140332), so correctly no new lmi30 exemption is added — this avoids the registries/KNOWN_MISSING_COMBINATIONS contradiction called out in prior precedent (Source: #6483). The DJL Serving version key is unchanged, so the in-place edit is appropriate. The PR looks clean; the only caveat is that static JSON tests don't verify actual ECR publication in ap-east-2, which should be confirmed manually.

_{Reviewed commit 2f61a3b. Automated review; verify before acting.}