Commit Graph

88 Commits (master)

Author SHA1 Message Date
Clark Boylan 78dd1225ba Bump container from python3.10 to python3.11
This matches what Zuul and Nodepool are doing. Getting off the older
images will also allow OpenDev to stop building them. We update the
unittest job to python 3.11 in the process to better cover what people
will deploy.

Note we wanted to update the base OS from bullseye to bookworm, but this
update involves upgrading openssl from 1.1.x to 3.x and the rehash
library which the registry depends on is not compatible with openssl
3.x. Getting to python3.11 on bullseye would at least allow us to stop
building python3.9 and python3.10 bullseye images.

Change-Id: Ie609a2f5f3c488cea8d98e78c9fa6353ebb78f62
2023-10-09 11:12:56 -07:00
Clark Boylan ce6722d215 Revert "Pull OpenDev images from quay.io"
This reverts commit 53371d7e86.

OpenDev is moving back to docker.io in order to continue doing
speculative testing of container images.

Depends-On: https://review.opendev.org/c/opendev/system-config/+/884256
Change-Id: I8cc8537f03e0a799db9123b2a12e542b911564b8
2023-05-24 11:20:53 -07:00
Clark Boylan 53371d7e86 Pull OpenDev images from quay.io
OpenDev is moving images to quay.io. This change updates zuul-registry's
use of those images to match. The depends on will ensure we don't merge
this before the move has occurred.

Depends-On: https://review.opendev.org/c/opendev/system-config/+/881932
Change-Id: I4e7b2003d5641d66dd283e5827cda87521e93d69
2023-05-05 11:47:19 -07:00
James E. Blair 40764b6e7a Publish container images to quay.io
Change-Id: If4b7596efd873acb8f06fddf016d9aff689b85ca
2023-04-26 09:59:32 -07:00
Clark Boylan 036e3adc73 Convert zuul-registry to nox
Tox v4 released and has introduced a number of compatibility problems.
Nox is an alternative to nox that is much simpler and uses standard
tools and zuul repos are switching to it. This change updates
zuul-registry.

Change-Id: I588842a0c47d0591b6dacbe28e96915e1b15819e
2022-12-29 10:49:39 -08:00
Clark Boylan c338fc970d Update the docker images to python 3.10
We do this to take advantage of python 3.10's speed improvements as
illustrated by Zuul proper. But also OpenDev would like to drop python
3.8 image builds to make room for python 3.11.

We add python3.10 unittesting to prevent regressing the docker images on
that version of python.

Change-Id: Ib2e39e0c5d09b4fdce40faa072fe51b55c8d7407
2022-10-14 15:31:12 -07:00
Mohammed Naser 8190671962 Fix "docker manifest create" issue
This patch resolves the issue that causes Docker to fail when
it runs the "docker manifest create" command since the registry
does not mention that it supports the 2.0 API inside it's
headers.

Change-Id: I777bd4218c822fa665f0d29f573a6ae120194284
2022-04-06 15:37:07 -04:00
Mohammed Naser 081352b299 tests: Add regression test for manifests
Due to a bug in Docker[1], it fails to create the manifest
manually due to a missing header when Docker runs a ping to
the API.  This has been fixed in the development branch but it
will likely take time for it to trickle down.

This is the first patch of two which will demonstrate the actual
failure, with another follow-up patch which will demonstrate
the fix.

[1]: https://github.com/docker/cli/issues/3161

Change-Id: I1f5c3121c58f93503be92c5ea3c4ae446cc44938
2022-04-06 15:36:52 -04:00
Zuul 20f50e0ae7 Merge "testing: add DEBUG flag to testing container" 2022-03-17 03:09:11 +00:00
Ian Wienand 0f48718523 testing: add DEBUG flag to testing container
Make sure we log all possible output in the container logs

Change-Id: I982d88619bfbadba23b9d4f0a99cf0661b7cc474
2022-03-04 09:55:07 +11:00
Ian Wienand 1592ec938a tox-py38 : don't run on Fedora
I'm not sure why I62f6c238de5c55b7673ae8b38a6ededdd77f4d4b added these
with Fedora; maybe it was the only 3.8 environment at the time.  I
don't think we want to run the tests there now.

Change-Id: Iee0e2b60e49e8149b045eaedccff034e5f5a1cfd
2022-03-04 06:45:21 +11:00
Ian Wienand 84f48df4c2 Update testing to Ubuntu Focal
Depends-On: https://review.opendev.org/c/zuul/zuul-jobs/+/831326
Change-Id: I5ca269f57866c4acf5c6e57c1146846e7cf50400
2022-03-04 06:45:21 +11:00
Ian Wienand 0601df0049 Fix and/or matching for image pre-conditions
These matches look like they should be "or" (if any of these images is
already there, fail), not "and".  This caused some confusion when the
image was being leaked (I722ba599fbc690d6cb967070c05215b98a73dcaf) as
this wasn't triggering.

Change-Id: Ic6dad7bbf9013e994eb80a54bc5191a96bd4be94
2022-03-04 06:45:21 +11:00
Ian Wienand 329f0a5195 podman: make sure we remove the pulled image
Currently we pull test/image here but do not clean it out.  This
interferes with the buildset-registry podman tests that happen
afterwards when using podman 3.4.  It's unclear if this is a feature
or a bug, see [1].

[1] https://github.com/containers/podman/issues/13383

Change-Id: I722ba599fbc690d6cb967070c05215b98a73dcaf
2022-03-04 06:45:21 +11:00
Ian Wienand 4c7c0dcd7a podman buildset testing: dump image list
Explictly dump the image list for easier debugging, and add a little
note about what's going on.

Change-Id: I27b3003a63d549c48a9326c807a7f14b97ba1dad
2022-03-04 06:45:21 +11:00
Zuul 3ce62dcc74 Merge "Add more robust testing of the registry" 2022-03-03 17:51:21 +00:00
Zuul ba3c104689 Merge "Perform atomic upload updates v2" 2022-03-03 17:51:19 +00:00
Clark Boylan 8dfb9dc968 Add more robust testing of the registry
We use a non trivial image now (the registry's image in fact) and then
push with 4 processes at a time every time we push to the test registry.
The idea here is we're generating concurrency in the system that should
trip over the bugs that we are finding if they still exist.

Change-Id: I4f03132fa0fad6f40806030b14d429d29036a42f
2022-02-28 14:19:03 -08:00
Clark Boylan 4213b96d3a Perform atomic upload updates v2
The way the registry was previously written if two concurrent uploads
of the same blob were happening one would fail to grab the lock and then
return early. The uploading client would then immediately HEAD the blob
and if it did so quickly enough would get a short size or 404. To avoid
this we need the upload to continue until all concurrent uploads are
complete.

To make this happen we treat upload chunks separately per upload so that
separate uploads cannot overwrite the chunks once they are moved to the
blob directory. We end up moving the chunks to the blob directory in
upload specific locations to facilitate this. Once that is done we can
atomically update the actual blob data from the chunks. In the
filesystem driver we concatenate the chunks into the blob then
atomically rename the result into its final blob/data location. This
ensures that we only ever return valid HEAD info for a blob, and that it
is only requested by the client once it exists.

This should be safe because the objects are hashsum addresses which
means their contents should be identical. If we end up moving one copy
into place then another atomically they will always have the same data
and size.

These logs from an OpenDev test job seem to capture this in action:

  # First upload is completing and grabs the lock
  2022-02-25 21:28:14,514 INFO registry.api: [u: 935f8eddbb9a4dab8dd8cc45ce7f9384] Upload final chunk _local opendevorg/gerrit digest sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343
  2022-02-25 21:28:14,576 DEBUG registry.storage: [u: 935f8eddbb9a4dab8dd8cc45ce7f9384] Locked digest sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343

  # Second upload attempts to complete but ends early without the lock
  2022-02-25 21:28:15,517 INFO registry.api: [u: e817d8fd6c464f80bf405581e580cbab] Upload final chunk _local opendevorg/gerrit digest sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343
  2022-02-25 21:28:15,578 WARNING registry.storage: [u: e817d8fd6c464f80bf405581e580cbab] Failed to obtain lock(1) on digest sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343
  2022-02-25 21:28:15,588 INFO registry.api: [u: e817d8fd6c464f80bf405581e580cbab] Upload complete _local opendevorg/gerrit digest sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343
  2022-02-25 21:28:15,589 INFO cherrypy.access.140551593545056: ::ffff:172.17.0.1 - - [25/Feb/2022:21:28:15] "PUT /v2/opendevorg/gerrit/blobs/uploads/e817d8fd6c464f80bf405581e580cbab?digest=sha256%3A0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343 HTTP/1.1" 201 - "" "docker/20.10.12 go/go1.16.12 git-commit/459d0df kernel/5.4.0-100-generic os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.12 \(linux\))"

  # Second upload completion triggers the HEAD requests that is either a
  # 404 or short read. This causes the second upload client to error.
  2022-02-25 21:28:15,605 INFO registry.api: Head blob _local opendevorg/gerrit sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343 not found
  2022-02-25 21:28:15,607 INFO cherrypy.access.140551593545056: ::ffff:172.17.0.1 - - [25/Feb/2022:21:28:15] "HEAD /v2/opendevorg/gerrit/blobs/sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343 HTTP/1.1" 404 735 "" "docker/20.10.12 go/go1.16.12 git-commit/459d0df kernel/5.4.0-100-generic os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.12 \(linux\))"

  # Now first upload has completed and the HEAD request by the first
  # upload client is successful
  2022-02-25 21:28:18,898 INFO registry.api: [u: 935f8eddbb9a4dab8dd8cc45ce7f9384] Upload complete _local opendevorg/gerrit digest sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343
  2022-02-25 21:28:18,898 INFO cherrypy.access.140551593545056: ::ffff:172.17.0.1 - - [25/Feb/2022:21:28:18] "PUT /v2/opendevorg/gerrit/blobs/uploads/935f8eddbb9a4dab8dd8cc45ce7f9384?digest=sha256%3A0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343 HTTP/1.1" 201 - "" "docker/20.10.12 go/go1.16.12 git-commit/459d0df kernel/5.4.0-100-generic os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.12 \(linux\))"
  2022-02-25 21:28:18,915 INFO registry.api: Head blob _local opendevorg/gerrit sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343 size 54917164
  2022-02-25 21:28:18,916 INFO cherrypy.access.140551593545056: ::ffff:172.17.0.1 - - [25/Feb/2022:21:28:18] "HEAD /v2/opendevorg/gerrit/blobs/sha256:0c6b8ff8c37e92eb1ca65ed8917e818927d5bf318b6f18896049b5d9afc28343 HTTP/1.1" 200 54917164 "" "docker/20.10.12 go/go1.16.12 git-commit/459d0df kernel/5.4.0-100-generic os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.12 \(linux\))"

Change-Id: Ibdf1ca554756af61247d705b2ea3cf85c39c2b83
2022-02-28 14:16:03 -08:00
Ian Wienand a3815dbd60 Fix podman install source
The PPA this is using is deprecated.  The ensure-podman role will
setup the repositories correctly for us from upstream and install
podman.

Change-Id: I4d04431499230a03ae685ebb21d5d88ffec7d679
2022-02-28 14:11:00 +11:00
Clark Boylan 19ccf5990e Revert "Atomically concatenate blob objects"
This reverts commit 0acf995175.

This changed the errors from short reads leading to manifest mismatches
to unknown blob errors. The unknown blob errors are due to not
responding to the HEAD requests until after all the data is written.
Either we get the HEAD request early and return a short size or we
return 404 and either way the end result is failure.

I'm not sure how what the solution is at this point but want to have
this revert ready in case this is desireable.

Change-Id: I6ba420e53e2091456db23c1c1cf4c76be04a4d03
2022-02-25 13:38:05 -08:00
Clark Boylan 0acf995175 Atomically concatenate blob objects
We are seeing problems where manifests are invalid because the size in
the manifest for blobs is smaller than the actual size of a blob. The
reason for this appears to be that the docker client will HEAD blobs to
get their size for use in the manifest, and zuul-registry will return a
HEAD value if the blob is on disk. With larger blobs concatenating the
chunks into the final blob location may be slow and we'll return a short
HEAD response while the blob is being concetenated.

Avoid this problem by concatenating into a tmpfile and then atomically
moving that file into its final position. The file length should be
complete at that point and HEAD will only see the path as existing once
it is complete.

Change-Id: I0c85fa5657106175140fbb8b8193659bcfe2d6c8
2022-02-24 14:49:39 -08:00
Clark Boylan 120cadf2f6 Update the registry docker image to bullseye
This updates the base image to bullseye. Buster has a shelf life now and
we should shift to bullseye.

Change-Id: Ia136695f00a9ba71fc8ffe984e9563e1061ff099
2021-12-09 15:29:31 -08:00
Ian Wienand 6439b16c04 Fix manifest HEAD response when looking up by label
Prior change Iaf6b83b61a470e8c5a61d18b7c241f9ca002c08a contained a bug
that and was returning an blank Content-Length for manifest HEAD
queries.  For this case, we have already read() the blob so we can
just return it's length for the HEAD query.

(the extant code was wrong for this case and self.storage.blob_size
was returning None, which got turned into 0 silently.  This leads to
the client reporting:

 failed commit on ref "manifest-sha256:ad38c...": unexpected commit digest
 sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855,
 expected  sha256:ad38c... failed precondition

I put this in for anyone googling who is seeing that e3b0c4... hash;
it's a clue that somehow you're trying to hash something empty.  This
slipped through because I tested pulling images, which worked, but it
fails when pulled in by docker build).

Change-Id: I7218843879ecd7939730060b6cee18af8190b888
2021-09-17 16:32:51 +10:00
Ian Wienand 43fb3fce3c Fix manifest HEAD requests
Manifest HEAD requests should return:

 Content-Length: <length of manifest>
 Docker-Content-Digest: <digest>

Currently we are not returning Content-Length.  Add this, and similar
to I089fa28bf16d4161507821452d6cf91d86818dc6 make sure it is actually
returned by disabling fiddling with encoding.

I think that Buildkit getting confused
(I5416694d861c5391fa0aebcebfd83d7c1b0a4e4d) is probably related to us
not returning the correct Content-Length here.  Thus I have reverted
these checks.  The standard definitely says these requests should
return both headers and a blank body; so if this is still causing
problems we should investigate further.

Change-Id: Iaf6b83b61a470e8c5a61d18b7c241f9ca002c08a
2021-09-14 06:07:46 +00:00
Ian Wienand 2b51524733 Do not accept missing sizes
The reason for missing sizes was traced back to our bad response to
HEAD requests for blobs (I089fa28bf16d4161507821452d6cf91d86818dc6).

Now that is fixed, we should not accept missing sizes from clients.

Change-Id: I2514ea01789a53f26ace345ec86177e1634dfa98
2021-09-14 06:07:29 +00:00
Ian Wienand 59b6bd32de Fix head_blob Content-Length return
As noted inline, a blank body falls into CherryPy code that will
delete the Content-Length.

The end result is that we are sending responses to blob HEAD requests
with an invalid Content-Length.

One consequence of this is that the "config" struct in manifests are
missing their "size" attribute.

[1] a7983fe61f/cherrypy/lib/encoding.py (L137)

Change-Id: I089fa28bf16d4161507821452d6cf91d86818dc6
2021-09-14 06:04:45 +00:00
Ian Wienand b88539964d Do not allow incorrect sized layers
This is a partial revert of I70a7bb5f73d1dddc540e96529784bb8c9bb0b9e3

The off-by-one error turned out to come from our range response
(I1fb1abf3c76ea8db7820caa90c97ddbf92997842).  There are no clients we
know of that send an incorrect size in the manifest; we should error
if we see that.

Revert the adding of layer sizes done with
Id5b1c5726fbe046b2f9f2994bf34f5fd7ecd90de and replace it with a hard
error.  I have tested both docker and podman pushes against this
change and both correctly set a size for each layer in the manifest
per [1].

Although I can not replicate it, the missing sizes might have already
been fixed upstream, or related to the aforementioned off-by-one
response we were giving.

[1] https://docs.docker.com/registry/spec/manifest-v2-2/#manifest-list-field-descriptions

Change-Id: Ibe061171bfd8ab6043b491bbab933bf277f8e12b
2021-09-14 05:54:50 +00:00
Ian Wienand ce2fb31a72 Fix range response
The range starts from zero, so we are returning one byte too many.
Docker echos this back to us in the manifest it uploads which is where
the extra byte is coming from.

This is actually the root cause of the off-by-one error worked around
in 134c942835.  A follow-on will clean
this up (Ibe061171bfd8ab6043b491bbab933bf277f8e12b).

Change-Id: I1fb1abf3c76ea8db7820caa90c97ddbf92997842
2021-09-13 08:23:37 -07:00
Ian Wienand 7100c360b3 filesystem: add file syncs
The "does the size on disk match the manifest" size checks in
I70a7bb5f73d1dddc540e96529784bb8c9bb0b9e3 appear to having a
false-positive on some changes.

One example job I found failed with

 Manifest has invalid size for layer
 sha256:9815a275e5d0f93566302aeb58a49bf71b121debe1a291cf0f64278fe97ec9b5
 (size:203129434 actual:185016320)

but when I went to look at the file on disk (quite some time later),
it was correct

 $ ls -l ./_local/blobs/sha256:9815a275e5d0f93566302aeb58a49bf71b121debe1a291cf0f64278fe97ec9b5
 -rw-r--r-- 1 root root 203129433 Sep  7 01:53 data

(well, off by one byte, but that's the problem worked-around by the
original change).

I think what happened here is that is that when we're getting into
multi-hundred megabyte layers there's plenty of chance for the writes
to join the upload chunks to have not flushed by the time we check it
when the manifest is uploaded.

Add some flush and sync points after upload and concatentation writes
to avoid this.

Change-Id: I46606287d41fa6745de7c8bfb31c6b0d28e32957
2021-09-07 14:12:34 +10:00
Ian Wienand 95261e654b swift: return size as int
I70a7bb5f73d1dddc540e96529784bb8c9bb0b9e3 put in logging messages that
assume the size coming back is a integer.  To keep this compatible
with the stat() returns from the file-system version, cast the
content-length to int.

Change-Id: Ic79e212865129abbc4011ad8ddf2c804c4374766
2021-09-06 11:19:59 +10:00
Ian Wienand 134c942835 Reject mismatched layer sizes, with some exceptions
The image manifest specification specifies a "size" for each layer
that " ... exists so that a client will have an expected size for the
content before validating. If the length of the retrieved content does
not match the specified length, the content should not be trusted."

This validates that a pushed manifest has the correct size for the
layers, and if it does not, returns an error.  A function is added to
clear a blob+metadata which essentially rolls-back all the layers from
the manifest (otherwise you get errors when trying again about
existing objects).

This is a change to the status quo, although I believe a correct one.
A flag is added if the old behaviour is required for whatever obscure
reason.

The logic was getting a bit tangled, so I've refactored slightly to
hopefully make it more understandable.

Current docker seems to have an issue where is misreports the size; we
put in a workaround for this since it has been identified.

[1] https://docs.docker.com/registry/spec/manifest-v2-2/#image-manifest

Change-Id: I70a7bb5f73d1dddc540e96529784bb8c9bb0b9e3
2021-09-03 08:50:38 -07:00
James E. Blair 0c03e1e054 Return "scope" in auth challenge
Containerd requires a "scope" in the www-authenticate header.
See https://github.com/containerd/containerd/issues/3556

Change-Id: I3f438c3595b8b864d47a735e736d309525d30a41
2021-07-31 18:31:38 -07:00
James E. Blair 720d091653 Also include missing size attributes in layers
Docker build can in some cases omit size attributes in the layer
entries in its manifests.  This isn't a critical error for podman,
but it does cause it not to draw the little progress arrows.  So
let's add them if they're missing too.

Change-Id: Id5b1c5726fbe046b2f9f2994bf34f5fd7ecd90de
2021-07-06 17:52:01 -07:00
James E. Blair 8f2629ed85 Add missing size to image configs
This is related to an incompatibility between docker and podman.

"docker build" produces image manifests that look like this:

    {'config': {'digest': 'sha256:abc',
                'mediaType': 'application/vnd.docker.container.image.v1+json'},
     'layers': [{'digest': 'sha256:def',
                 'mediaType': 'application/vnd.docker.image.rootfs.diff.tar.gzip',
                 'size': 5678},
        ...

"podman build" manifests look like this:

    {'config': {'digest': 'sha256:abc',
                'mediaType': 'application/vnd.docker.container.image.v1+json',
                'size': 1234},
     'layers': [{'digest': 'sha256:def',
                 'mediaType': 'application/vnd.docker.image.rootfs.diff.tar.gzip',
                 'size': 5678},
        ...

Podman includes the size attribute for the image config, but Docker
does not.  If you "docker build" and "docker push" to a zuul-registry,
and then "podman pull" from it, it will fail because of the missing
size.

One solution to this would be to simply "podman build" instead of
"docker build".  That's probably best.

But somehow, when the result of "docker build" is pushed to Docker Hub,
and then that is used with "podman pull", it works.  We can surmise that
Docker Hub is correcting the manifest with the missing data in that case.
To maintain compatability, let's do the same.

Also, add a missing content-type header on blob GETs.  This doesn't seem
to be important, but it's more correct.

Change-Id: I0db0dbf9775b02438880624bcf98d2b8f4d2575c
2021-07-06 17:46:26 -07:00
James E. Blair 0d97c0738e Add content-length headers and debug messages
According to the docs, these content-length headers should be
present, so include them.  We should also return a 202 on the PUT
rather than a 204.

None of that seems to matter, but as long as that's the case, why
not match the spec?

Also, adjust some log lines to match others and add a few more
useful lines.

Change-Id: Ib06d282891984918f369a562d075ad2b8c7349e2
2021-07-06 17:46:17 -07:00
James E. Blair 326cdca31e Make TLS optional
So that the registry may be run behind a TLS terminating proxy,
make the TLS configuration optional.

Change-Id: I234ab825d809fc2d5cd31a192d235902a2fff065
2021-07-06 17:46:15 -07:00
James E. Blair b635c65cf3 Add a restricted mode (read authentication required)
Enable running the registry in a mode where authentication is required
for pulling images.  This could be useful in an environment where even
an intermediate or buildset registry should require authentication to
pull images.  Or it could make this more useful as a general registry
(that's not a priority use case for this project, but this doesn't add
much complexity).

If a "read" level user is specified, then we assume that anonymous
read access should not be allowed.

Change-Id: I1455a1031590ff0206a4b6da0d8c08093cf0e3cd
2021-07-06 17:46:13 -07:00
James E. Blair bf98edd796 Build images on bionic
The projectatomic PPA for focal seems defunct.

Change-Id: I4951dbadb9b202b8d5fe268114b37d74e591b178
2021-07-06 17:27:57 -07:00
Zuul 8da8973d6e Merge "Run unittests on python 3.8" 2021-04-28 18:05:32 +00:00
Zuul 3fed15c01a Merge "Bump to python 3.8 base images" 2021-04-28 18:05:24 +00:00
Clark Boylan 9782d9b739 Handle ns parameter in get_blob
This is a followon from the previous change and updates the get_blob
method to also handle an http GET ns parameter. The buildx client
sends this parameter when getting blobs as well:

  cherrypy.access.139663382723600: ::ffff:172.17.0.1 - - [02/Feb/2021:00:04:09] "GET /v2/upstream/image/blobs/sha256:358792b44b713f905789d54d9733e75c702792522c07f812bf873b5ffc5efe77?ns=docker.io HTTP/1.1" 404 735 "" "containerd/1.4.0+unknown"

As with the manifests we simply accept the paramater and ignore it.

Ianw found more info in containerd's git log:

  adeba792f1

Change-Id: Ibcf08c26844bf514a003b9809743540e6d320170
2021-02-01 16:28:23 -08:00
Clark Boylan 7fbd69dafd Handle ns parameter on manifest GET/HEAD
Some image clients (like the one in buildx) send a namespace parameter
when getting manifests. Cherrypy responds with a 404 if it doesn't know
about parameters so we add an ns parameter to get_manifest.

Note that it is possible we need to add this to blob gets as well, but
we'll take this one step at a time.

Change-Id: I1538e07242133a26021ba38eff886b5f8f7402e3
2021-02-01 11:17:20 -08:00
Clark Boylan e155fa9383 Update pyjwt version to >=2.0.0,<3.0.0
Pyjwt recently made a 2.0 release. This release is not compatible with
the 1.x series code. We fix the registry to be compat with pyjwt 2.x and
then exclude 1.x.

More details here:
  https://pyjwt.readthedocs.io/en/stable/changelog.html#jwt-encode-return-type

Change-Id: I5c8e6fa0bb593efc70d57413b6d3274883a5a9b5
2021-02-01 10:46:09 -08:00
Paul Belanger ea4b756f70 Add upload-docker-image release job
This will allow us to publish container images to docker when we git
tag. Also add tags field to image_vars, like we do for zuul and nodepool
images.

Change-Id: I9d4cde7a15c6bc57de62ebe3dcafe209e147aefc
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
2020-11-19 13:22:07 -05:00
Paul Belanger 20de79e8d2 Begin publishing to pypi
This adds build / release jobs for pypi / wheels for zuul-registry.

Change-Id: Ie198a173bd6e2e315cef2d91417aaed57a27592e
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
2020-11-17 16:30:22 -05:00
James E. Blair 9fe19a5abf Prioritize returning manifest lists
Docker expects the registry to return the best kind of manifest
when multiple manifests are available.  To do that, make a priority
list of what we think are best, and return the first available one
that is also supported by the client.  We prefer manifest lists to
individual manifests so that multi-arch images work.

Change-Id: Ice0db4180d3b5d294ed0cdd6d0d598698e1e3762
2020-07-14 15:28:21 -07:00
James E. Blair 8f1f0705f7 Handle blob upload races
If two uploads for the same digest race, we could have hit an error
when finalizing the upload.  The chunks are concatenated into the
final file and then removed -- that removal would raise an exception
if the chunk was already deleted.

To avoid this, we add a lockfile to the digest to detect the race
condition, and if we determine that we did not win the race, we
delete our upload files and return success, assuming the other
contestant won.  This lockfile has a 300 second timeout, so if
the other upload ended up failing, a later push can resolve the
situation.

Change-Id: I1ed7e132ede44a8594aa5539e9caf2fcef030ac4
2020-05-06 09:24:02 -07:00
Monty Taylor cce0058810 Run unittests on python 3.8
We bumped the images, let's bump the unit tests too.

Change-Id: I67ad9851e07b4066f5df6e876ef5c237f6cf89e4
2020-05-05 12:59:06 -05:00
Monty Taylor 614055e4f9 Bump to python 3.8 base images
We bumped zuul to 3.8, let's follow suit.

Change-Id: I0e7e602e6dcd9c479096e3652c7c00bbbc551795
2020-05-05 09:24:01 -05:00