| 14 Sep 2020 |
 awg | In reply to@_slack_opencontainers_UGGPC8W85:matrix.org
The goal for OCI artifacts is to create an ecosystem where we don’t actually know, or even need to know all the types. Just like there’s no official list of file types for windows or linux. That said, it would be great to know and we thought of having a clearing house in the OCI Artifacts repo. We decided to not block anyone and to have folks register with IANA to “own” their type.
But, a list of types to advertise would be great.
makes sense. as a registry implementor, i'm interested in such a list so that we can "understand" various types and give a richer user experience for them. for now in the DO registry we do that only for container images, but helm charts are an obvious next step and other types would be interesting as they become more common. | 15:17:01 |
 Steve Lasker | In reply to@_slack_opencontainers_U013LP307S7:matrix.org
makes sense. as a registry implementor, i'm interested in such a list so that we can "understand" various types and give a richer user experience for them. for now in the DO registry we do that only for container images, but helm charts are an obvious next step and other types would be interesting as they become more common. Gotcha. We did/do have a PR for registry operators to have a set of schemas artifact authors can provide so registry operators can present icons, localized strings and such.
The other side of things is, should a registry limit the mediaTypes? File systems don’t limit file extensions. But, if you provide extra info, the file system can provide icons and text for the type.
So, DO might want to relax the limits to enable an ecosystem. As you start to show icons for Image and Helm, artifact authors like OPA, CNAB, Singularity and WASM would ask, “hey, how do I get that for...) | 19:58:05 |
| awg | In reply to@_slack_opencontainers_UGGPC8W85:matrix.org
Gotcha. We did/do have a PR for registry operators to have a set of schemas artifact authors can provide so registry operators can present icons, localized strings and such.
The other side of things is, should a registry limit the mediaTypes? File systems don’t limit file extensions. But, if you provide extra info, the file system can provide icons and text for the type.
So, DO might want to relax the limits to enable an ecosystem. As you start to show icons for Image and Helm, artifact authors like OPA, CNAB, Singularity and WASM would ask, “hey, how do I get that for...) ah, yeah, we don't limit types at all - i've tested with helm and it works. it just doesn't look "right" in the UI, since we assume everything is a container image. | 20:00:19 |
| awg | In reply to@_slack_opencontainers_U013LP307S7:matrix.org
ah, yeah, we don't limit types at all - i've tested with helm and it works. it just doesn't look "right" in the UI, since we assume everything is a container image. i was in touch with the CNAB folks late last year and i know they had tested our registry, too. definitely interested in providing better UX around all kinds of artifacts in the future. | 20:00:49 |
| awg | In reply to@_slack_opencontainers_U013LP307S7:matrix.org
i was in touch with the CNAB folks late last year and i know they had tested our registry, too. definitely interested in providing better UX around all kinds of artifacts in the future. thanks for the info - this is super helpful. i'll keep an eye on the artifacts project, and also bring it up with our designers as we think about future UX for our registry. | 20:03:24 |
| 15 Sep 2020 |
| Steve Lasker | Just saw this from the Harbor folks:
https://www.cncf.io/blog/2020/08/25/harbor-is-extending-its-reach-with-key-image-distribution-features-and-support-for-machine-learning-artifacts/
They really took advantage of the config object to store additional data, not in the layers. | 17:18:17 |
| 16 Sep 2020 |
|  George Terry joined the room. | 22:22:40 |
| George Terry changed their profile picture. | 22:22:44 |
| 17 Sep 2020 |
 Omar Paul | In reply to@_slack_opencontainers_UGGPC8W85:matrix.org
Just saw this from the Harbor folks:
https://www.cncf.io/blog/2020/08/25/harbor-is-extending-its-reach-with-key-image-distribution-features-and-support-for-machine-learning-artifacts/
They really took advantage of the config object to store additional data, not in the layers. What does this mean, generally, for the OCI specs and forward looking thoughts? | 19:59:00 |
| 18 Sep 2020 |
| Steve Lasker | In reply to@_slack_opencontainers_UR09UUBA4:matrix.org
What does this mean, generally, for the OCI specs and forward looking thoughts? It and the recent Solo.io wasm work are the most recent implementations of OCI Artifacts. So, it means our registries will have more usage of more types and we should get the mediaType publication of well known types out. Which, I’m struggling to find where I have as a PR. hmm | 15:07:05 |
|  v joined the room. | 20:55:48 |
| v changed their profile picture. | 20:56:48 |
| v | hey folks! I'm implementing an OCI registry for Django and running into some design questions - specifically if a blob should be allowed to be associated with more than one image, or if it's more secure to only allow 1:1. I've expressed my concern in detail here - https://github.com/opencontainers/distribution-spec/issues/180#issuecomment-695074478 would appreciate any quick thoughts/feedback so I can refactor what I currently have! | 20:56:48 |
| v | In reply to@_slack_opencontainers_UGJKRG59C:matrix.org
hey folks! I'm implementing an OCI registry for Django and running into some design questions - specifically if a blob should be allowed to be associated with more than one image, or if it's more secure to only allow 1:1. I've expressed my concern in detail here - https://github.com/opencontainers/distribution-spec/issues/180#issuecomment-695074478 would appreciate any quick thoughts/feedback so I can refactor what I currently have! I was originally wanting to associate images with blobs based on tags, before the manifest upload, but it seems like the name doesn't include a tag (just the repository) so the association can only be done via the final request to upload a manifest, and either the registry needs to parse the manifest to find the blob digests (and create a link) or just have no ide (which seems like a bad idea when a manifest/tag deletion request is done because we can't clean up) | 21:04:10 |
| v | In reply to@_slack_opencontainers_UGJKRG59C:matrix.org
I was originally wanting to associate images with blobs based on tags, before the manifest upload, but it seems like the name doesn't include a tag (just the repository) so the association can only be done via the final request to upload a manifest, and either the registry needs to parse the manifest to find the blob digests (and create a link) or just have no ide (which seems like a bad idea when a manifest/tag deletion request is done because we can't clean up) Why would a registry server need a repository name to upload a blob to in the case that the association isn't made until the final upload of the manifest? | 21:07:36 |
 Derek McGowan | Redacted or Malformed Event | 21:53:55 |
| Derek McGowan | In reply to@_slack_opencontainers_UGJKRG59C:matrix.org
Why would a registry server need a repository name to upload a blob to in the case that the association isn't made until the final upload of the manifest? For blob to image, that is really a matter of how your registry implements permissions. The common way to do it is to associate blobs at a repository level, since associating at an image level is not really possible without clients sending specifying the exact image when requesting blobs. To keep storage efficient, a common hash based blob storage can be used for the large data, then keep all the repository to blob associations to gate access of those blobs, this preservers permission and efficiency | 21:54:09 |
| Derek McGowan | In reply to@_slack_opencontainers_ULL23GEGN:matrix.org
For blob to image, that is really a matter of how your registry implements permissions. The common way to do it is to associate blobs at a repository level, since associating at an image level is not really possible without clients sending specifying the exact image when requesting blobs. To keep storage efficient, a common hash based blob storage can be used for the large data, then keep all the repository to blob associations to gate access of those blobs, this preservers permission and efficiency For cleaning manifests when last tag is deleted, that is another policy thing. You can have a policy where manifests are automatically removed, kept forever, or deleted based on some staleness criteria | 21:54:55 |
| Derek McGowan | In reply to@_slack_opencontainers_ULL23GEGN:matrix.org
For cleaning manifests when last tag is deleted, that is another policy thing. You can have a policy where manifests are automatically removed, kept forever, or deleted based on some staleness criteria nothing in the specification requires keeping manifests, the only expectation is that if the manifest exists the blobs which is links to should be available | 21:55:51 |
| Steve Lasker | In reply to@_slack_opencontainers_ULL23GEGN:matrix.org
nothing in the specification requires keeping manifests, the only expectation is that if the manifest exists the blobs which is links to should be available Basically, there's a garbage collection issue. Layers can be de-duped across repositories. But that means there's reference counting that must be tracked.
This has been a debate. From an ACR perspective, we're seeing customers not just ask, but demand better deletion capabilities.
Not just because they don't want to pay for so much additional storage, but their registries have old content that has vulnerabilities. If the images are so old, and not kept for archival reasons, or they're builds that never got deployed, they need to be deleted. | 21:58:34 |
| 19 Sep 2020 |
| v | In reply to@_slack_opencontainers_UGGPC8W85:matrix.org
Basically, there's a garbage collection issue. Layers can be de-duped across repositories. But that means there's reference counting that must be tracked.
This has been a debate. From an ACR perspective, we're seeing customers not just ask, but demand better deletion capabilities.
Not just because they don't want to pay for so much additional storage, but their registries have old content that has vulnerabilities. If the images are so old, and not kept for archival reasons, or they're builds that never got deployed, they need to be deleted. Derek McGowan what are your thoughts on having blobs not associated to any specific repository, but shared between them (and only have a cleanup policy if no longer linked to any one repository?) | 20:18:31 |
| 20 Sep 2020 |
| Derek McGowan | In reply to@_slack_opencontainers_UGJKRG59C:matrix.org
Derek McGowan what are your thoughts on having blobs not associated to any specific repository, but shared between them (and only have a cleanup policy if no longer linked to any one repository?) v that's how docker/distribution and containerd do blob storage | 05:06:23 |
| v | In reply to@_slack_opencontainers_ULL23GEGN:matrix.org
v that's how docker/distribution and containerd do blob storage ah cool! I've been thinking this over the past few days, I started with an Image model that is linked to a repository and some number of blobs, where the blob was a foreign key to the image, that wasn't a great idea because I couldn't easily share blobs between Images, and I also realized that it was hugely redundant. A quick fix would use a many to many relationship between blobs and images, but that would require a lot of care in cleanup, and still somewhat risky to have different users sharing blobs. The next thing I tried and was thinking about was removing a Blob's association to any image or repository, but (even without knowing the details) that felt not super secure, what if someone could upload a malicious blob to someone else's images? What if Docker didn't make the right choice to do that? So the third approach that I updated to use yesterday was the approach you mentioned in https://opencontainers.slack.com/archives/CGJFFCPS7/p1600466049007800?thread_ts=1600462606.004200&cid=CGJFFCPS7 - repository linking to blobs to gate access to repository owners, and also create more nested organization on the filesystem. It also (sort of?) feels like it makes sense for the OCI spec that requires the name of the repository for push transactions. Anyway, so that's what I'm testing for now - we'll see if my thinking changes in time! | 17:51:09 |
| 23 Sep 2020 |
|  四番町ちよだ joined the room. | 10:47:54 |
|  Michael Brown joined the room. | 17:04:41 |
| 30 Sep 2020 |
| Steve Lasker | A few slides on the discussion of Artifact Collections: https://github.com/SteveLasker/drafts/tree/main/media | 23:13:32 |
| Steve Lasker | I saved .pptx and and .pdf | 23:13:53 |
| 15 Oct 2020 |
|  vignesh joined the room. | 12:01:09 |
| 22 Oct 2020 |
|  morgan joined the room. | 20:38:27 |
| 25 Oct 2020 |
|  Theo Salvo joined the room. | 16:47:11 |
