You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ggcr's Daemon implementation appears to now support daemon.Image and daemon.Write and appears that we could use it for the local implementation. If the daemon package has feature-parity with remote, I believe we could get many benefits from using daemon:
Enable daemons to "pull" non-container-images (ORAS) or otherwise unpullable images, by dynamically rewriting remote-image metadata and/or layers before saving to the daemon during a pull.
This looks like it will be important for enabling buildpackages on Windows, which now require a Microsoft-proprietary base-layer for them to be stored on the daemon.
More shared code between remote and local - perhaps eventually a single implementation with flags for remote/local.
Use an upstream implementation to which Docker is more directly concerned with supporting.
@micahyoung We moved away from the ggcr daemon implementation awhile ago due to performance issues. Specifically the ggcr daemon package requires us to export and import base layers that already exist in the daemon. Our implementation has shortcut logic that avoids this. AFAIK this issues has not been addressed in ggcr yet
ggcr's Daemon implementation appears to now support
daemon.Image
anddaemon.Write
and appears that we could use it for thelocal
implementation. If thedaemon
package has feature-parity withremote
, I believe we could get many benefits from usingdaemon
:remote
andlocal
- perhaps eventually a single implementation with flags for remote/local.daemon
package: https://github.com/google/go-containerregistry/tree/master/pkg/v1/daemonThe text was updated successfully, but these errors were encountered: