-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
enable http registries as ocm repositories #676
enable http registries as ocm repositories #676
Conversation
95fd337
to
841487b
Compare
54b29cd
to
09d4c3b
Compare
a334ec4
to
71dd942
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I'm honestly a bit against this. There is a reason for not supporting insecure repositories. ocm-controller is using self-signed certificates to set up testing registries that use HTTPS. It's super easy to create a secure registry for testing. In the wild you should never EVER use an insecure HTTP registry. So I don't see the point of this change. |
I'm open for discussion. Currently, you will at least get a warning if you use http and if you do not specify a scheme, it will default to https. |
@fabianburth you're right, the lower the entry for getting started the better the adoption. :) |
You can use mkcert to generate a self-signed, trusted cert, than when you are launching the registry, just pass the cert in as an environment property and everything should work. :) |
So, I'm not strictly talking about command line usage here. Let's consider integration tests and say you start your application and also your registry in cluster. Now, it might already be kind of a hassle to get your application to trust the certificate, mightn't it? |
Not really, no. In fact, we use an HTTPS registry in our e2e tests here: https://github.com/open-component-model/ocm-controller/tree/main/e2e You'll see that we deploy cert-manager, generate a certificate, download it, install in the local store using mkcert, and done. Everything is running with HTTPS. This is all we needed to do to get things running https://github.com/open-component-model/ocm-controller/blob/main/hack/prime_test_cluster.sh. We only test using HTTPS. The same goes for github actions which is our CI. |
…tory>[:<tag>][@<digest>]
… (or anyname:port/repo:version)
The oci upload handler performed an path.Join() on the reference, which removes double slashes - also converting e.g. http:// to http:/ and causing the upload to fail.
… ocm repo notations Before, there was no particular regex for correctly parsing these notations. Therefore, ocm assumed they are specifying ctfs and attempted to interpret them as filepaths.
For ocm commands such as ocm transfer cv <source> <target>, some users confused the notation of the target ocm repository with the notation of components and attempted to use double slashes. If the transfer command was attempted with e.g. OCI::ghcr.io/fabianburth//github.com/mycomponent, the double slash was cleaned up to a single slash and the component was uploaded under ghcr.io/fabianburth/github.com/mycomponent/github.com/mycomponent.
6ce207e
to
e25b642
Compare
Description
So far, it was not possible for the ocm tooling to communicate with OCI registries with
http
, but only withhttps
. The reason therefore was primarily that the scheme was not considered in the parsing and it defaulted tohttps
.This PR extends the code, especially the parsing rules, to be able to also handle
http
.Furthermore, it was not possible to specify
localhost
in OCI commands (e.g.ocm get artifact
).This PR also extends the code to be able to handle
localhost
.Consequently, the following specifications are now possible:
For OCI commands (such as ocm get artifact):
http://example.com/repo:version
http://localhost:8080/repo:version
localhost:8080/repo:version
(The port, thus:8080
is required, here. So,localhost/repo:version
is not possible, since e.g.localhost/example:1.0.0
is also a valid dockerhub artifact reference and would therefore be ambiguous.)localhost//repo:version
(The scheme, thushttp://
can be omitted, if the host is separated from the repo with an unambiguous double slash (//).)http://localhost:8080//repo:version
(A combination of the previous two formats is also possible, although kind of unintuitive.)For OCM commands (such as ocm transfer):
OCIRegistry::http://localhost:80/test//github.com/example
(The type, thusOCIRegistry::
is required)OCIRegistry::localhost:80/test//github.com/example
(Works as well without the scheme, but will default tohttps
)and the variations with an actual domain
OCIRegistry::http://example.com:80/test//github.com/example
http://example.com:80/test//github.com/example
example.com:80/test//github.com/example
(will default tohttps
)example.com/test//github.com/example
(will default tohttps
)...
Furthermore, since using http might potentially be insecure and should only be used in test scenarios, the user should get a warning. To enable this, a corresponding log message was introduced on log level warn and the general default log level for the cli tool was changed from error to warn.
Short types for repositories that were expected to work (e.g. oci) are now registered with corresponding repository and repository spec handlers.
make generate
also checks whether the examples are running. This failed on mac, since the component of the 01-getting-started did not contain an arm64 darwin executable due to a mistake in its build. This is now fixed, so after the next releasemake generate
will be callable on mac again. Until then, one can call e.g. go generate ./cmds/ocm/... manually.What type of PR is this? (check all applicable)
Added tests?
Added to documentation?
Adjusted the existing ocm references and oci references cli documentations and added additional examples for the
most common use cases.
Checklist: