Skip to content

Conversation

dmcgowan
Copy link
Member

@dmcgowan dmcgowan commented Jul 17, 2025

Moves packages associated with imagesand layers to daemon. Moves the relevant internal and pkgs into daemon as well.

@dmcgowan dmcgowan requested a review from samuelkarp as a code owner July 17, 2025 23:22
@dmcgowan dmcgowan moved this to In Progress in go modules transition Jul 17, 2025
@dmcgowan dmcgowan added this to the 29.0.0 milestone Jul 17, 2025
@dmcgowan dmcgowan added the release-blocker PRs we want to block a release on label Jul 17, 2025
@dmcgowan dmcgowan force-pushed the move-image-daemon branch from f5597ad to 75231e8 Compare July 18, 2025 00:03
@dmcgowan dmcgowan requested a review from tianon as a code owner July 18, 2025 00:03
@dmcgowan dmcgowan force-pushed the move-image-daemon branch from 75231e8 to 02bd9a3 Compare July 18, 2025 00:18
@dmcgowan dmcgowan self-assigned this Jul 18, 2025
Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

This needs more work; it will break our cli

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

Made a first pass, but may need to look at some in more depth

Copy link
Member

Choose a reason for hiding this comment

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

image/spec was kept because it previously defined the image specification; we should consider removing it instead of moving. It has no place as an internal package.

"github.com/docker/docker/daemon/internal/image"
"github.com/docker/docker/daemon/internal/layer"
"github.com/docker/docker/image"
Copy link
Member

Choose a reason for hiding this comment

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

Do we still need this package at all? I started looking at this, but didn't finish; it looks to be used for "pre-1.9 compatibility";

v1ImgCreated := time.Unix(0, 0)
v1Img := image.V1Image{
// This is for backward compatibility used for
// pre v1.9 docker.
Created: &v1ImgCreated,
}
if i == len(img.RootFS.DiffIDs)-1 {
v1Img = img.V1Image
}
rootFS := *img.RootFS
rootFS.DiffIDs = rootFS.DiffIDs[:i+1]
v1ID, err := v1.CreateID(v1Img, rootFS.ChainID(), parent)
if err != nil {
return nil, err
}
v1Img.ID = v1ID.Encoded()
if parent != "" {
v1Img.Parent = parent.Encoded()
}

Copy link
Member

Choose a reason for hiding this comment

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

This one will require changes to our build-scripts;

LDFLAGS="${LDFLAGS} \
-X \"github.com/docker/docker/dockerversion.Version=${VERSION}\" \
-X \"github.com/docker/docker/dockerversion.GitCommit=${GITCOMMIT}\" \
-X \"github.com/docker/docker/dockerversion.BuildTime=${BUILDTIME}\" \
-X \"github.com/docker/docker/dockerversion.PlatformName=${PLATFORM}\" \
-X \"github.com/docker/docker/dockerversion.ProductName=${PRODUCT}\" \
-X \"github.com/docker/docker/dockerversion.DefaultProductLicense=${DEFAULT_PRODUCT_LICENSE}\" "

moby/hack/make.ps1

Lines 487 to 492 in b10cbd9

$ldflags = "-X 'github.com/docker/docker/dockerversion.Version="+$dockerVersion+"'"
$ldflags += " -X 'github.com/docker/docker/dockerversion.GitCommit="+$gitCommit+"'"
$ldflags += " -X 'github.com/docker/docker/dockerversion.BuildTime="+$env:BUILDTIME+"'"
$ldflags += " -X 'github.com/docker/docker/dockerversion.PlatformName="+$env:PLATFORM+"'"
$ldflags += " -X 'github.com/docker/docker/dockerversion.ProductName="+$env:PRODUCT+"'"
$ldflags += " -X 'github.com/docker/docker/dockerversion.DefaultProductLicense="+$env:DEFAULT_PRODUCT_LICENSE+"'"

Copy link
Member

Choose a reason for hiding this comment

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

pkg/tarsum also seems to define the specification; is it something to be preserved and moved separate from this repo?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think buildkit should own it, we have no use for it in the future in the engine but it is still useful for build

Copy link
Member

Choose a reason for hiding this comment

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

It looks like the only remaining use of this is in builder/remotecontext` (for the classic builder); do we know if it's still needed there? How does BuildKit do this? (ISTR it had its own implementation, which made me curious if we can share that if it's still needed); I'm not very familiar with how/why it's used exactly;

tsh := &tarsumHash{hdr: hdr, Hash: sha256.New()}
tsh.Reset() // initialize header
return tsh, nil
}
type tarsumHash struct {
hash.Hash
hdr *tar.Header
}
// Reset resets the Hash to its initial state.
func (tsh *tarsumHash) Reset() {
// comply with hash.Hash and reset to the state hash had before any writes
tsh.Hash.Reset()
tarsum.WriteV1Header(tsh.hdr, tsh.Hash)
}

Copy link
Contributor

@vvoland vvoland left a comment

Choose a reason for hiding this comment

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

SGTM

dmcgowan added 9 commits July 24, 2025 12:10
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
dmcgowan added 14 commits July 24, 2025 12:12
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
…networking

Signed-off-by: Derek McGowan <derek@mcg.dev>
Signed-off-by: Derek McGowan <derek@mcg.dev>
@dmcgowan dmcgowan force-pushed the move-image-daemon branch from 3d4e2ca to 0abcdb7 Compare July 24, 2025 19:21
@dmcgowan dmcgowan changed the title Move remaining daemon packages Move remaining image packages to daemon Jul 24, 2025
Copy link
Contributor

@austinvazquez austinvazquez left a comment

Choose a reason for hiding this comment

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

Been trending positive on this but giving it the official thumbsup. My mindset is we can continue to rehome inside the daemon module once it is created before stabilizing the module and creating a tag there.

@dmcgowan
Copy link
Member Author

@austinvazquez I think the general approach we agreed on earlier is to at least put all the daemon stuff that we know is not used in daemon. The other packages we know are being legitimately used, we can keep them outside. That gives us the option of ensuring that nothing under daemon is imported anywhere.

@austinvazquez
Copy link
Contributor

@dmcgowan, okay most of this move still makes sense to me. The one I'm having trouble now with is pkg/tarsum. Would that stay in place?

@dmcgowan
Copy link
Member Author

tarsum isn't used by any active projects, only used internally. There is probably more we can move to internal after a bit more vetting/splitting.

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

"github.com/docker/docker/internal/unshare"
"github.com/docker/docker/daemon/internal/unshare"
Copy link
Member

Choose a reason for hiding this comment

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

Not for this PR; considering if this package could be moved to a module in moby/sys; it looks very self-contained and stable, and we currently maintain a fork of the code in moby/go-archive/chrootarchive.

@thaJeztah
Copy link
Member

tarsum isn't used by any active projects, only used internally. There is probably more we can move to internal after a bit more vetting/splitting.

Yes, there's a bunch of things that need curating. Split cruft from relevant parts.

@thaJeztah
Copy link
Member

Double-checked some of my older comments; I left some of them "unresolved" as a reminder for some follow-ups. I just merged my PR in docker/cli to remove the registry dependency there, which paves the way for more cleaning up;

Let's bring this one in 👍 🎉

@thaJeztah thaJeztah merged commit 57e1cb2 into moby:master Jul 25, 2025
213 of 215 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in go modules transition Jul 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-blocker PRs we want to block a release on
Projects
Development

Successfully merging this pull request may close these issues.

4 participants