The original model the idea here is the proxy centralizes
verification of things like digest. However in practice,
this causes reading to be seriously awkward; ref
https://github.com/containers/containers-image-proxy-rs/issues/79
(Basically `FinishPipe` blocks the metadata channel)
Also, I have a project to implement a registry frontend to
`containers-storage:` and a core problem with `GetBlob` right
now is it *requires* the blob size up front even though the
underlying Go logic doesn't.
Moving to a "raw" interface solves that too. In this new
raw API, we return two file descriptors, one for the data
and one for the error channel, which contains a JSON
serialization of an error.
For the error type we reuse the existing "is error retryable"
and expose that back to the client.
We also (backwards compatibly) add this new error code
for the existing APIs.
Signed-off-by: Colin Walters <walters@verbum.org>
I was experimenting with images with lots of layers (> 200) and
this invocation was incorrectly adding the entire response
into what was intended as the metadata plane.
`GetManifest` and `GetConfig` (even those are relatively small)
still always return their data over a pipe, same as blobs.
Add a new `GetLayerInfoPiped` that does the same so we
can easily get this information for images with a lot of layers.
Signed-off-by: Colin Walters <walters@verbum.org>
In PR review for a different issue, the question of what happens
if we hit overflow for the imageid serial was hit. This feels
pretty unlikely; if I did the math right, it'd require opening
an average of 136 images per second to overflow it in a year.
Nevertheless, in practice what we're sending on the wire is just a JSON
number, and if we extend this to the "max safe JSON number" of 2^53,
it'd take 285,616,414 images per second to overflow in a year, going
from implausible to probably impossible.
With a bit more work of course, we could make this a sparse mapping
and reuse freed numbers, but eh.
Signed-off-by: Colin Walters <walters@verbum.org>
gopkg.in/check.v1 hasn't had any commit since Nov 2020.
That's not a immediate issue for a test-only dependency, but
because it hides access to the standard library *testing.T,
eventually it will become limiting.
Also, using the same framework for unit and integration tests
seems practical.
This is mostly a batch copy&paste job, with a fairly high risk
of unexpected breakage.
Also, I didn't take much time at all to carefully choose between
assert.* and require.*; we can tune that as failures show up.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In some code I'm writing I want to be able to cleanly test if an
image exists, as distinguished from other errors like authentication
problems, network flakes etc.
As best I can tell, the containers/image abstraction doesn't
offer a clean way to do this.
For now, I chose the route of adding the ugly string error matching
here for the two cases I care about (docker v2s2 registry and oci
directories), so my Rust code can operate in terms of clean
`Option<Image>`.
Signed-off-by: Colin Walters <walters@verbum.org>
Mostly just name changes that should not change behavior, apart
from ioutil.ReadDir -> os.ReadDir avoiding per-item lstat(2) in
one case.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... as found by (golangci-lint run).
Note: this does not add (golangci-lint run) to the Makefile
to ensure the coding standard.
(BTW golangci-lint currently fails on structcheck, which doesn't
handle embedded structs, and that's a years-long known unfixed
limitation.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
> receiver name should be a reflection of its identity; don't use generic names such as "this" or "self" (ST1006)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Sadly...I swear I had tested this at one point, but it was
*definitely* not the intention that we just return the container
runtime configuration.
I need a method to return the full image configuration. At some point
I must have accidentally added a redundant `.Config`.
This whole new method `GetFullConfig` is like `GetConfig` but
returns the whole image configuration. A specific motivation
here is that it's only in the image configuration that we can
stick arbitrary metadata (labels) that will survive a round trip through
docker schema v2.
To fix compilation on MacOS.
I think actually we want to use this pervasively in our tests
on Linux; it doesn't really matter when run inside a transient
container, but `PDEATHSIG` is useful for persistent containers (e.g.)
toolbox and when running outside of a pid namespace, e.g. on a host
system shell directly or in systemd.
Signed-off-by: Colin Walters <walters@verbum.org>
We need to support manifest lists. I'm not sure how I missed this
originally. At least now we have integration tests that cover this.
The issue here is fairly subtle - the way c/image works right now,
`image.FromUnparsedImage` does pick a matching image from a list
by default. But it also overrides `GetManifest()` to return the
original manifest list, which defeats our goal here.
Handle this by adding explicit manifest list support code. We'll
want this anyways for future support for `GetRawManifest` or so
which exposes OCI manifest lists to the client.
Signed-off-by: Colin Walters <walters@verbum.org>
I debated adding "reverse dependency testing" using
https://crates.io/crates/containers-image-proxy
but I think it's easier to reuse the test infrastructure here.
This also starts fleshing out a Go client for the proxy (not
that this is going to be something most Go projects would want
versus vendoring c/image...but hey, maybe it'll be useful).
Now what I hit in trying to use the main test images is currently
the proxy fails on manifest lists, so I'll need to fix that.
Signed-off-by: Colin Walters <walters@verbum.org>
