Skip to content

Conversation

@ChengyuZhu6
Copy link
Member

Fixes: #4573

@ChengyuZhu6 ChengyuZhu6 force-pushed the transfer branch 2 times, most recently from 285c273 to 156a92a Compare November 5, 2025 15:51
@AkihiroSuda AkihiroSuda added this to the v2.3.0 milestone Nov 6, 2025
@ChengyuZhu6 ChengyuZhu6 force-pushed the transfer branch 21 times, most recently from b5584fe to 18b0448 Compare November 14, 2025 03:54
@ChengyuZhu6 ChengyuZhu6 force-pushed the transfer branch 5 times, most recently from a49ea0a to f66db0d Compare November 23, 2025 14:43
@ChengyuZhu6
Copy link
Member Author

ChengyuZhu6 commented Nov 25, 2025

Most image management operations now use the transfer service:

  • Standard image pull/push operations
  • Multi-platform image handling
  • Progress reporting and streaming
  • Basic registry authentication
  • Image import/export (load/save)

Limitations

Due to current transfer API constraints, the following features continue to use the legacy implementation:

1. IPFS Registry and Nondistributable Artifacts

Reason: The transfer service API does not support custom registry resolver implementations.

Affected features:

  • IPFS registry functionality (ipfs:// protocol)
  • Nondistributable artifact handling (e.g., Windows base layers)

Status: These features remain on the legacy resolver-based approach until the transfer API supports custom resolvers.

2. Containerd 1.7.x Compatibility Issue

Issue: When using containerd 1.7.x daemons, registry options like WithDefaultScheme("http") and WithHostDir() are silently ignored.

Technical details:

  • nerdctl uses containerd v2.2 client library which supports these options
  • Options are properly serialized into protobuf messages
  • However, containerd 1.7.x's UnmarshalAny() implementation doesn't process these fields
  • Only authorizer and headers are handled in 1.7.x

Impact:

  • Localhost registry operations may fail with: "http: server gave HTTP response to HTTPS client"
  • Custom hosts.toml configurations are not applied on 1.7.x

@ChengyuZhu6
Copy link
Member Author

ChengyuZhu6 commented Nov 25, 2025

For limitation 2, there are two potential solutions:

  1. Implement containerd version detection in nerdctl to use different code paths;
  2. Backport to containerd 1.7.x

For limitation 1, there are two potential solutions:

  1. IPFS Registry and Nondistributable Artifacts remain on the legacy resolver-based approach.
  2. containerd transfer API supports custom resolvers

@ChengyuZhu6
Copy link
Member Author

@AkihiroSuda @ktock

@AkihiroSuda
Copy link
Member

Thanks @ChengyuZhu6

For limitation 2, there are two potential solutions:

  1. Implement containerd version detection in nerdctl to use different code paths;
  2. Backport to containerd 1.7.x

For limitation 1, there are two potential solutions:

  1. IPFS Registry and Nondistributable Artifacts remain on the legacy resolver-based approach.
  2. containerd transfer API supports custom resolvers

2 in the long term, 1 in the short term

@ChengyuZhu6 ChengyuZhu6 marked this pull request as ready for review November 27, 2025 07:19
@ChengyuZhu6 ChengyuZhu6 force-pushed the transfer branch 7 times, most recently from f2e210d to d3b9cab Compare November 27, 2025 10:59
Switch image operations to the transfer API with structured progress reporting
and improved TLS/HTTP fallback behavior. Introduce shared helpers for
credentials, error classification, progress rendering, and transfer-based
import/tag/save flows, updating tests to reflect the new UX.

Signed-off-by: ChengyuZhu6 <hudson@cyzhu.com>
Add remote snapshot annotations and transfer unpack config
for stargz, soci, and fuse-overlayfs snapshotter plugins.

Signed-off-by: ChengyuZhu6 <hudson@cyzhu.com>
Add version detection to automatically select Transfer service (2.0+)
or legacy resolver methods (< 2.0) for better compatibility.

Signed-off-by: ChengyuZhu6 <hudson@cyzhu.com>
enable_remote_snapshot_annotations = "true"
[[plugins."io.containerd.transfer.v1.local".unpack_config]]
platform = "linux"
snapshotter = "overlayfs"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if this config is not specified?
i.e., what happens with the default config?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default, it would be

[[plugins."io.containerd.transfer.v1.local".unpack_config]]
  platform = "linux/amd64"(matches the host's OS/Architecture)
  snapshotter = "overlayfs" 
  differ = "walking"     

"github.com/containerd/containerd/v2/pkg/progress"
)

// From https://github.com/containerd/containerd/blob/v2.2.0-rc.0/cmd/ctr/commands/image/pull.go#L240-L473
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we import the package from containerd/containerd to reduce code clones?

Copy link
Member Author

@ChengyuZhu6 ChengyuZhu6 Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The progress handling code is in cmd/ctr/commands/images, not in pkg/ or core/, so it cannot be imported directly.
And I removed displayName() function that splits names by '-':

func displayName(name string) string {
	parts := strings.Split(name, "-")
	for i := range parts {
		parts[i] = shortenName(parts[i])
	}
	return strings.Join(parts, " ")
}

which would break display for image names containing - (e.g., ubuntu-base )

}

// SupportsFullTransferService checks if the containerd version fully supports the Transfer service.
// While containerd 1.7 has Transfer service, full support is only available in 2.0+.
Copy link
Member

@AkihiroSuda AkihiroSuda Nov 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// While containerd 1.7 has Transfer service, full support is only available in 2.0+.
// While containerd 1.7 has Transfer service, full support is only available in 2.0+.
// The following features are missing in containerd 1.7:
// - [ADD MISSING FEATURES]

snapshotter = "fuse-overlayfs"
[[plugins."io.containerd.transfer.v1.local".unpack_config]]
platform = "linux"
snapshotter = "overlayfs"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of complicating the config.
What happens if these lines are missing?
ctr doesn't need them AFAICS?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default, it would be

[[plugins."io.containerd.transfer.v1.local".unpack_config]]
  platform = "linux/amd64"(matches the host's OS/Architecture)
  snapshotter = "overlayfs" 
  differ = "walking"     

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This config is required to specify which snapshotter the transfer service should use when unpacking images. We define multiple unpack targets:

  • overlayfs for standard OCI images
  • stargz / soci for lazy-pulling support

Without this, containerd defaults to basic unpacking and won't leverage stargz/soci snapshotters needed for lazy-pulling.

And if we only configure stargz in unpack_config, then all images would be forced to use the stargz snapshotter during transfer/unpacking, even standard OCI images that don't support lazy-pulling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Refactor the image management code to use the Transfer service

2 participants