atomic type awkward about skopeo HOT 5 CLOSED

How would that work?

If we start with the OpenShift API URL, we have a plausible way to discover the docker registry API URL (it doesn’t work, but hopefully it will one day).

Given the docker registry API URL, how would we find the corresponding OpenShift API URL?

from skopeo.

Independently of the primary concern above, WRT the --atomic CLI option:

“Transports” (the designated by the prefix before a colonwhen referring to an image for skopeo) are a fairly fundamental abstraction in containers/image and skopeo copy. The docker: / atomic: prefix is there precisely so that any application, whether skopeo, ocid, or anything else, can use any image recognized by containers/image without understanding the specifics of it. If skopeo had a special --atomic option then every other user of containers/image would have to have its own equivalent to the --atomic option; generic software which didn’t support this option wouldn’t allow using the OpenShift API.

(Of course the user can just forget about OpenShift and manually discover the location of the embedded docker registry, and use that using the plain docker:// image names, but that means docker registry-like behavior and no OpenShift API use.)

(Also, of course it is possible to build a CLI on top of containers/image which does not expose these transport designation prefixes—and atomic is one such a CLI already. skopeo is, as much as practical, just a thin dumb wrapper over containers/image.)

Finally, if #189 is high-priority, please just say so; it is ugly but doable, I’m just not working on it right now because I am guessing (perhaps incorrectly) that it is not a critical deliverable.

from skopeo.

Given the docker registry API URL, how would we find the corresponding OpenShift API URL?

The same way we define the lookaside cache using the atomic.conf configuration file.

My primary concern is that users expect to reference by fully qualified docker registry name. They're not aware of signing servers, they just have an image. Some are not even aware of imagestreams and project namespace.

“Transports” (the designated by the prefix before a colonwhen referring to an image for skopeo) are a fairly fundamental abstraction in containers/image and skopeo copy.

Yes, and I don't intend to put deliverables at risk for this. My specific proposal is probably a bad one.

from skopeo.

The same way we define the lookaside cache using the atomic.conf configuration file.

It’s fairly unattractive to commit to an UI which requires the user to input two bits of data when one uniquely identifies the other (in principle, though not in current implementation)

from skopeo.

Both this and #189 could be resolved by adding a registry URI to the atomic: type.

    atomic:registry_uri:port/namespace/stream:tag

In this way the end user references a docker image as they expect to, regardless of their awareness of the openshift cluster. We get the registry URI and port "for free", resolving #189.

from skopeo.