zot: a production-ready vendor-neutral OCI image registry - images stored in OCI image format, distribution specification on-the-wire, that's it!
Documentation for zot
is located at: https://zotregistry.dev
Code of conduct details are here.
zot - A scale-out production-ready vendor-neutral OCI-native container image/artifact registry (purely based on OCI Distribution Specification)
Home Page: https://zotregistry.dev
License: Apache License 2.0
zot: a production-ready vendor-neutral OCI image registry - images stored in OCI image format, distribution specification on-the-wire, that's it!
Documentation for zot
is located at: https://zotregistry.dev
Code of conduct details are here.
When making HEAD request to nonexistent repository name, Zot produces the following error:
{
"level": "error",
"error": "repository: not found",
"caller": "/go/src/github.com/anuvu/zot/pkg/api/routes.go:249",
"time": "2020-02-12T21:41:02.455401195Z",
"message": "unexpected error"
}
However, the status code on the HTTP response is 500, rather than 404
{
"level": "info",
"module": "http",
"clientIP": "********",
"method": "HEAD",
"path": "/v2/pmengelbert/notexist/manifests/latest",
"statusCode": 500,
The relevant switch/case is here:
https://github.com/anuvu/zot/blob/92241d17cba09ef17d591daec2081ae0ef695b49/pkg/api/routes.go#L245
It isn't checking for errors.RepoNotFound, and is defaulting to 500 response
As a user and contributor, I want a document describing the project security response procedures and how to report a security issue.
Acceptance Criteria:
SessionLogger being a nested func means that all the logs include
"caller":"/root/go/src/github.com/anuvu/zot/pkg/log/log.go:113"
and it's always the same.
If there's a way to reorganize the code to get a useful Caller(), great, otherwise can we leave it out and make the logs a little easier to read?
Thanks!
As a user, I need a consistent documentation formatting standard.
Acceptance Criteria
This standard should be used for all documentation including root docs such as README, CONTRIBUTING, etc.
We could just follow the single binary model.
Zot should provide an extension mechanism to implement additional features outside the OCI specification. Extensions provides a way to implement experimental/draft features to the OCI community and gain experience with these use cases. If and when these features are standardized, zot will promote the extensions to core feature set and can be the reference implementation of the specification.
All extensions are compiled in to the zot binary and can be selectively enabled/disabled using runtime configuration.
Zot supports two types of extensions. Inline extensions which are called as requests are being processed by zot. Asynchronous extensions which are called after an event finished.
Extension points that are called inline with a repository feature like push image, pull image and list, create, update, delete manifests and all operations. We will use the middleware pattern to register the extension points that will extend each of this feature and can react to these events inline as they are being processed by zot.
Async extensions are invoked in their own context in reaction to an event. For example CRUD operations on an image or a repository. There is no ordering guarantee for the extensions, all of them may be invoked in parallel.
Each extension must be explicitly configured and only configured extensions are registered with runtime and invoked appropriately. Here is a sample configuration
{
"extensions": [
{"scan": { "scanInterval" : "10m" }},
{"query": {"queryPort" : 6000}},
]
}
If I create images called 'host:v1' and 'proj1/dest:v1', then curl of /v2/_catalog will show me 'host' and 'proj1'. I think it would be nice to give the full path of each of those.
We will want to support running a cluster of zot servers.
When a blob is uploaded, it should be distributed to all the nodes.
When fetching an image, the client should be able to fetch each
layer blob from a different server to load balance.
Hello guys,
Why are you using sudo for skopeo operations?
Example: https://github.com/project-zot/zot/blob/main/Makefile#L50
Please publish a public container image on Quay/Docker Hub (or other) in order to use for OCI conformance purposes
When building with go 1.13.5 the following error happens:
--- PASS: TestAPIs (0.03s)
PASS
coverage: 67.8% of statements
ok github.com/anuvu/zot/pkg/storage 1.080s coverage: 67.8% of statements
golangci-lint --version || curl -sfL https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | sh -s v1.17.1
/bin/sh: 1: golangci-lint: not found
golangci/golangci-lint info checking GitHub for tag 'v1.17.1'
golangci/golangci-lint info found version: 1.17.1 for v1.17.1/linux/amd64
golangci/golangci-lint info installed ./bin/golangci-lint
golangci-lint --config .bazel/golangcilint.yaml run --enable-all ./cmd/... ./pkg/...
pkg/log/log.go:1: /usr/local/go/src/path/match.go:200:15: DecodeRuneInString not declared by package utf8 (typecheck)
package log
pkg/storage/storage.go:1: /usr/local/go/src/path/filepath/match.go:215:15: DecodeRuneInString not declared by package utf8 (typecheck)
package storage
pkg/api/auth.go:1: /usr/local/go/src/fmt/scan.go:1200:16: DecodeRuneInString not declared by package utf8 (typecheck)
package api
pkg/cli/root.go:1: /usr/local/go/src/strings/strings.go:980:20: DecodeRuneInString not declared by package utf8 (typecheck)
package cli
cmd/zot/main.go:1: /usr/local/go/src/strconv/quote.go:405:12: ValidString not declared by package utf8 (typecheck)
package main
cmd/zot/main_test.go:1: /usr/local/go/src/encoding/json/fold.go:83:20: DecodeRune not declared by package utf8 (typecheck)
package main_test
pkg/api/controller_test.go:1: /home/zendril/go/pkg/mod/github.com/json-iterator/[email protected]/stream_str.go:275:19: DecodeRuneInString not declared by package utf8 (typecheck)
package api_test
pkg/cli/root_test.go:1: /usr/local/go/src/bytes/reader.go:98:18: DecodeRune not declared by package utf8 (typecheck)
package cli_test
pkg/compliance/v1_0_0/check_test.go:1: /usr/local/go/src/strconv/quote.go:405:12: ValidString not declared by package utf8 (typecheck)
package v1_0_0_test
pkg/storage/storage_test.go:1: /usr/local/go/src/regexp/regexp.go:967:22: DecodeRuneInString not declared by package utf8 (typecheck)
package storage_test
make: *** [Makefile:27: check] Error 1
Looks like it is related to golangci/golangci-lint#658 and is fixed.
As a project viewer, I would like to quickly understand the future plans for the project.
Acceptance Criteria:
zot currently lacks access control support. A needed feature if a single instance needs to be shared across multiple tenants.
dist-spec conformance container is available - use this in our ci/cd pipeline so that we don't break conformance (ever).
jdolitsky 12:12 PM
Ok, we now have a public image for dist-spec conformance suite :tada:
ghcr.io/opencontainers/distribution-spec/conformance:<COMMIT|TAG>
Example:
docker run --rm \
-v $(pwd)/results:/results \
-w /results \
-e OCI_ROOT_URL="https://r.myreg.io" \
-e OCI_NAMESPACE="myorg/myrepo" \
-e OCI_USERNAME="myuser" \
-e OCI_PASSWORD="mypass" \
-e OCI_TEST_PULL=1 \
-e OCI_TEST_PUSH=1 \
-e OCI_TEST_CONTENT_DISCOVERY=1 \
-e OCI_TEST_CONTENT_MANAGEMENT=1 \
-e OCI_HIDE_SKIPPED_WORKFLOWS=0 \
-e OCI_DEBUG=0 \
-e OCI_DELETE_MANIFEST_BEFORE_BLOBS=0 \
ghcr.io/opencontainers/distribution-spec/conformance:db4cc68
Right now, we need to pass a config alias with each command. Instead we can make it optional and make user able to choose a config as default.
For example
$ zot images remote-zot
Instead of this we could have a default config and then the command will look like
$ zot images
We can display the CVEs with highest priority on the top of the list.
As a user, I want a list of all the project's direct software dependencies and their respective licenses.
Acceptance Criteria:
A good example output is https://github.com/kubernetes/cloud-provider-aws/blob/master/THIRD-PARTY-LICENSES.
Currently, zot supports only mutual TLS and htpasswd authN. Would be useful to add LDAP support so that can hook up to Windows AD (for example)
As a project owner, manager or maintainer, I want to clearly communicate the governance model for this project.
Acceptance Criteria:
There is a Dockerfile in the repo, but it is only used for development purposes
$ zot config -l
$ zot config add main https://test-url.com
$ zot config -l
main https://test-url.com
$ zot config add main https://test-url.com
$ zot config -l
main https://test-url.com
main https://test-url.com
Fix:
$ ./bin/zot config -l
$ ./bin/zot config add main https://test-url.com
$ ./bin/zot config -l
main https://test-url.com
$ ./bin/zot config add main https://test-url.com
Error: config: config name is used. see 'zot config -l'
Usage:
zot config add <config-name> <url> [flags]
Flags:
-h, --help help for add
Useful variables:
url zot server URL
showspinner show spinner while loading data [true/false]
verify-tls verify TLS Certificate verification of the server [default: true]
Keep a separate audit log to track only API actions (separate from verbose logs)
As a project manager, maintainer, or contributor, I would like to quickly analyze existing issues and PRs by applying label filters to understand what work needs to be triaged, assigned, completed, etc. and to help me manage the backlog.
The goal is not to create every label we think we may need as this list can evolve.
Review and update label taxonomy to enable visibility of:
Acceptance Criteria
As a new contributor, I want instructions on how to setup a best practice development environment to work on and debug the project code and other assets.
Acceptance Criteria:
@pmengelbert pointed out rightly that:
DELETE Manifest
Delete the manifest identified by name and reference. Note that a manifest can only be deleted by digest.
Currently, supports only "BASIC", need "BEARER token" support as well.
Also, so we don't clobber LDAP server if configured as authN backend.
zot needs to be "nicer" when deleting images meaning blobs referenced in the manifest must be deleted safely as well. Currently, we expose the APIs and leave it to the user to handle this logic.
This also leads to the garbage collection feature.
As a potential user or contributor, I would like to read about the project, find documentation, and browse recent activity on a curated website.
Additional issues can be created and linked back to this parent issue.
Acceptance Criteria:
As a contributor or user, I would like to engage with the community on a regular call to discuss features, architecture, support issues, and other community topics.
Acceptance Criteria:
This is a defense-in-depth against layers being modified while on disk.
Remove it, have tests autogenerate one, and show in README to create one with htpasswd.
Right now it looks like Zot is a fantastic registry if I want to run it on a single machine. I'm particularly drawn to the LDAP support even though my preferred authentication only speaks LDAP by proxy. What I don't see is a way to run zot horizontally available. Is there no way to run Zot on top of a remote object store or similar option with nonlocal storage?
At present a single zot instance have only one single storage i.e being specified in config file e.g
"storage":{
"rootDirectory":"/tmp/zot"
}
but now we want zot to be scalable in terms of storage and restriction is to be done using single zot server instance.
CLI needs search command to list repositories and the images inside them. We can utilize existing distribution spec APIs.
conformance tests run in the upstream ci/cd pipeline, but would be useful for developers to be able to run these locally.
If there are no matching results for "ImageListWithCVEFixed" query, it is returning error: search: no fixed tag found
It should just return an empty list without any error message
As a user or contributor, I want a dedicated communication channel to work with project maintainers, other contributors, and users.
Acceptance Critera:
Possible Communication Channels
Currently, we support listing/searching images within a repo, but we have found it useful to also retrieve a list of images given a layer hash.
Hello - please see these instructions for how to certify zot as OCI-conformant: https://github.com/opencontainers/oci-conformance/blob/master/instructions.md
As the distribution spec has not yet reached 1.0, please simply use "v1.0-pre" as the spec version number. For example, open a PR on opencontainers/oci-conformance containing the following files:
distribution-spec/v1.0-pre/zot/README.md
distribution-spec/v1.0-pre/zot/report.html
distribution-spec/v1.0-pre/zot/junit.xml
distribution-spec/v1.0-pre/zot/PRODUCT.yaml
Please reach out if you have any questions.
As per discussion in [1], there is a requirement to generate a compliance check report in html or json.
zot uses goconvey [2] for driving unit tests and by extension, the compliance checks. goconvey has a reporting [3] package that could help with this.
References:
[1] https://groups.google.com/a/opencontainers.org/forum/m/#!topic/dev/JCpfBI-_woQ
[2] https://github.com/smartystreets/goconvey
[3] https://godoc.org/github.com/smartystreets/goconvey/convey/reporting
As a community member, I want to understand what the acceptable code of conduct is for participating in this project.
Acceptance Critera:
Currently when requesting the "/v2/" endpoint with bearer auth enabled, the Www-Authenticate header returns something like this:
Www-Authenticate: Bearer realm="https://<my_url>/auth/token",service="<my_url>",scope="repository:repo:pull"
This is due to the underlying library using a default value of "repo" for repository name when none is provided. This would cause issues, for example, if the registry literally had a repository named "repo".
Instead, the Www-Authenticate header should use a scope such as "repository::<action>":
Www-Authenticate: Bearer realm="https://<my_url>/auth/token",service="<my_url>",scope="repository::pull"
As a prospective contributor, I want documentation explaining the process and expectations for contributing to this project.
Acceptance Criteria:
Don't assume that the reader of this document has any background knowledge of the project, acronyms, etc. This document should enable self-service startup for new contributors.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.