-
Notifications
You must be signed in to change notification settings - Fork 54
duffle build followed by duffle export should work #828
Comments
Another idea: This would still require |
Agreed, it's not always appropriate for
That feels like a clean solution, but it's non-trivial. We would need to extend pivotal/image-relocation to support that (or, if that's not feasible, see if there is a different library for writing the OCI image layout).
I think that behaviour would be rather surprising. Also, the user can issue |
Looking into this solution. |
@itowlson Would you care to review vmware-archive/image-relocation#18? |
@glyn I don't feel qualified to review it at a code level, but the approach looks good and I agree with your comment about error reporting. Thanks! |
See cnabio/duffle#828 (comment). Bump the go-containerregistry dependency and use a corresponding version of docker. Handle an empty image name more gracefully (than panicking).
This is implemented by bumping pivotal/image-relocation to pick up the docker daemon support. Fixes cnabio#828
It turns out that the option of exporting images from the docker daemon is unsound because the docker daemon makes no guarantee to create the same content digest for an image as the image's repository (which belongs to a specific registry with specific compression algorithms etc.). So we are back to the drawing board with this issue. The remaining options appear to be:
|
I think a combination of 1 and 3:
|
Compare cnab-to-oci behaviour, which is analogous to export:
So I'm not sure about making export push all images. Suppose some images cannot be pushed because they are read-only for the current user - the push will fail. Also, I'm a little nervous about the time period between |
Unassigning so someone else can take this. I won't be able to get round to it for some time. |
Sorry to be naive here but why are layers coupled to a registry store? If I don't have a registry, I have an image (made up of layers which are SHA'd). Layers have to be transportable and cryptographically the same (otherwise, what's the point of docker?). Is there something else that is coupling an image that isn't even pushed to a registry? Let's say I pull down hello-world and tag is without a registry prefix. Now I duffle up hello-world. Can't duffle just write the tars from the image I have? Easier said than done I know. 🌻 |
@squarism maybe a bit of background will help. Each image has two digests. The so-called repository digest depends on the compressed form of the image and compression can vary by registry. Then there is an image id which is a digest of the uncompressed form of the image and so is registry independent. If you include a digest in an image reference, it's a repository digest. Some tools don't preserve the repo digest. For instance, if you docker pull/tag/push, the repo digest can change even though the uncompressed image stays the same. (Tools based on https://github.com/google/go-containerregistry, which is ultimately what |
If you do a
duffle build
followed by a (full-bundle)duffle export
then you get a baffling error (per #824), the significance of which is "you need to push the invocation image first," even though you may already have the invocation image in your local Docker registry as a result ofduffle build
.The reason that Duffle always attempts an image pull is so that it can work in environments where there is no local Docker daemon (thanks @glyn for the explanation). But this makes for a non-smooth build-then-export experience, not made easier by the cryptic error.
Some possible solutions:
duffle build
could always push the invocation image. @glyn has pointed out that this avoids problems where the user does aduffle build
followed byduffle export -t
(manifest only bundle). At the moment, the exported thin bundle will Work On My Machine TM, but fail when I give it to someone else because I haven't published the image. Downside is that maybe I don't want to put my invocation image up in public just yet; it also makes it harder to test locally, e.g. using Kind - these problems could be mitigated by aduffle build --push-image=false
option.duffle export
could check whether there is a local Docker daemon, and if so check that before resorting to a pull.Or something else of course!
The text was updated successfully, but these errors were encountered: