-
Notifications
You must be signed in to change notification settings - Fork 201
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
Artifact registry support #65
Conversation
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com>
Signed-off-by: Steve Lasker <StevenLasker@Hotmail.com> Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
…n-spec into Contributing Signed-off-by: Steve Lasker <stevenlasker@hotmail.com>
I'll reiterate what I've said in every meeting on this topic so far: even though I strongly believe in this use case, I'm not sure that a specification for artifact registries should live in the Open Containers Initiative. However, in the meantime this still might be a good place to work on the idea. I'm also still not convinced that we've come to a consensus on a cohesive strategy for reusing the existing distribution spec in a way that satisfies everyone. From our previous discussion, it seemed like we still require alignment from Docker's side of CNAB to have confidence in a model that everyone can properly leverage. |
|
||
## OCI Artifact Extensibility | ||
|
||
The distribution spec was initially based on docker images and the [OCI Image spec](https://github.com/opencontainers/image-spec/). As new artifact types surfaced, it became a logical use case to leverage the common elements of distribution to store and retrieve additional artifacts. This spec will reference *images* as one type of artifact, with specifics on how to differentiate different types of artifacts. |
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.
It would be good to explain why it is desirable to store non-image artefacts in a registry. Does this only really make sense for artefacts which reference images?
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.
As a spec, I struggled with how much "pitch" to put into the spec, as opposed to speaking to the details. I've written a few different posts, done presentations to set the overall context:
- Blog Post: Cloud Native Artifact Registries evolve from Docker Container Registries
- PowerPoint: Leveraging OCI Distribution for new Cloud Native Artifacts
Do you think we should put more of the pitch here? Are you looking for what type of artifacts to store?
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.
As a spec, I struggled with how much "pitch" to put into the spec, as opposed to speaking to the details. I've written a few different posts, done presentations to set the overall context:
Thanks but I don't think it would be appropriate to reference these in the spec.
Do you think we should put more of the pitch here?
Yes, but not framed as a sales pitch. I'm looking for rationale of when it makes sense to use this feature.
Are you looking for what type of artifacts to store?
Yes. In particular, does it make any sense to store an artefact that does not reference images?
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.
Agree we shouldn't reference these within the spec. I was more providing context on how I was framing things, outside the spec. To provide a funnel of the scenarios, to the specifics.
As for when and what artifact types, I don't know if we should attempt to limit. The question I ask in the above Cloud Native Rejekts talk is; why would you create Yet Another Storage Solution (YASS).
Registries have become ubiquitous. It's hard to see modern workloads that don't use containers. Even IoT devices and cars are running containers because of their packaging, isolation, patching, testing and deployment models. But, lets assume you have an optimized environment that doesn't require container images. Could you justify the engineering effort to build YASS? Or, would you just implement one of the current distribution solutions, and store the artifact types in it?
Can somebody from Docker/DockerHub please weigh in on this approach and any potential shortcomings? Quay? ECR? GCR? Would love to see the hubs come together on a standard approach for mulitartifact support, whether it is how Steve has proposed, or some alternation. Here is probably the most significant piece, which is on how registries reason over artifact types on the manifest level:
The rest of the changes are about new file |
I'll sum up my recommendation from the OCI call earlier
|
re: new project for @opencontainers/tob, have you decided what you will call this and who will put forth the proposal? happy to work with them |
SGTM |
Hi folks,
I’m out for a few days of vacation, but will be back Monday for follow-up to the call and all the feedback from Derek, Mike and others.
Steve
|
I've create the new TOB issue here: opencontainers/tob#59 |
I think this effort has sufficiently become its own thing. Any references can be done in a separate PR now. |
Additions to enhance distribution for supporting additional artifact types, such as Helm Charts, Singularity Images for High Performance Computing workloads, Open Policy Agent Bundles