feat: update SDK to use latest LMI v30 image for sdk v3.x

[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: register 0.38.0-lmi30.0.0-cu130 in KNOWN_MISSING_COMBINATIONS (ap-east-2), consistent with prior versions

Testing

• pytest tests/unit/image_uris/test_djl.py in sagemaker-core: 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.}

[github-actions]

🟡 Low: The 0.38.0-lmi29.0.0-cu130 entry is now stale: after this PR the 0.38.0 config key resolves to the lmi30.0.0-cu130 tag, so no test will ever look up the lmi29 combination. It's harmless to leave it, but you could remove it to keep KNOWN_MISSING_COMBINATIONS aligned with what the config actually produces.