fix(serve): support aliased hub content names in private hub deploys#6039
Open
e-davidson wants to merge 2 commits into
Open
fix(serve): support aliased hub content names in private hub deploys#6039e-davidson wants to merge 2 commits into
e-davidson wants to merge 2 commits into
Conversation
added 2 commits
July 17, 2026 00:08
CreateHubContentReference accepts a custom HubContentName, but the SDK always looks up hub content by model_id, so a reference named differently from the public model id fails with ResourceNotFound. Add optional hub_content_name to JumpStartConfig and thread it through from_jumpstart_config; when set, _build_for_jumpstart resolves hub content by the reference's actual name. Verified E2E against a live private hub with an execution role that has zero S3 permissions: an aliased ModelReference now deploys successfully with SageMaker brokering artifact access through the hub content reference.
…aliased names Unit tests (extends the aws#5985 file, shared setup hoisted to a module-level _build_jumpstart_builder helper per package convention): - model_reference_arn propagation regression test guarding the aws#6036 fix (supersedes the subset assertions added there) - CreateModel payload chain test: drives the real unmocked path _build_for_jumpstart -> _prepare_container_def_base and asserts the container definition carries S3DataSource.HubAccessConfig.HubContentArn for hub builds and omits it for public builds -- the assertion that would have caught the v3.15.1-v3.16.0 regression - hub_content_name lookup and config threading tests Integration tests (slow_test, self-provisioning with full teardown): - test_deploy_with_no_s3_execution_role: zero-S3 execution role deploy, asserts HubAccessConfig on the created Model (service-side contract) - test_deploy_with_aliased_hub_content_name: aliased reference deploy Verified red->green at every layer: 4 unit tests and both integ tests fail on v3.16.0 baseline; all pass with the fixes (integ verified live in us-east-1 with a real hub, zero-S3 role, 2 passed in 38s).
e-davidson
requested a deployment
to
manual-approval
July 17, 2026 00:09 — with 
GitHub Actions
Waiting
GitHub Actions
Waiting
e-davidson
requested a deployment
to
manual-approval
July 17, 2026 00:09 — with
GitHub Actions
Waiting
GitHub Actions
Waiting
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
Deploying a JumpStart model from a private hub via
ModelBuilder.from_jumpstart_config(hub_name=...)fails withResourceNotFoundwhen the hub'sModelReferencewas created with a customHubContentName. TheCreateHubContentReferenceAPI accepts an aliased name, but the SDK always looks up hub content bymodel_id, so aliased references are unreachable.This is the remaining defect after #5985 (hub_arn derivation) and #6036 (
model_reference_arnpropagation /HubAccessConfig).Fix
Optional
hub_content_nameonJumpStartConfig, threaded throughfrom_jumpstart_config; when set,_build_for_jumpstartresolves hub content by the reference's actual name (3 files, +17 lines).Test coverage
This PR also adds the regression coverage that would have caught the
HubAccessConfigregression that shipped in v3.15.1-v3.16.0:Unit (
tests/unit/test_private_hub_artifact_resolution.py, extends the #5985 file):model_reference_arnpropagation regression test guarding the Fix private hub #6036 fix (supersedes the subset assertions added there)_build_for_jumpstart -> _prepare_container_def_baseand asserts the container definition carriesS3DataSource.HubAccessConfig.HubContentArnfor hub builds and omits it for public buildshub_content_namelookup + config threading tests_build_jumpstart_builder()helper per package conventionIntegration (
tests/integ/test_private_hub_artifact_resolution.py,slow_test, self-provisioning with full teardown):test_deploy_with_no_s3_execution_role: creates an execution role with zero S3 permissions, deploys from a private hub, asserts the created Model carriesHubAccessConfig(the service-side brokered-access contract unit tests cannot reach)test_deploy_with_aliased_hub_content_name: deploys a reference named differently from the model_idVerification (red -> green at every layer)
Live runs used a real private hub +
ModelReferenceand an IAM role with no S3 permissions; all resources (hub, references, role, endpoints) cleaned up.Replaces #6035, which predated #6036 and carried a now-redundant duplicate of the propagation fix.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.