!EkxQprmxKedbJsEbZM:matrix.org

Open Container Initiative [#artifact-registry]

63 Members
Discussion of the Open Container Initiative distribution-spec and artifact-spec. Bridged through to #artifact-registry on https://opencontainers.slack.com/.3 Servers

Load older messages


SenderMessageTime
5 Mar 2021
@_slack_opencontainers_U01QQHQKZAM:matrix.org_slack_opencontainers_U01QQHQKZAM joined the room.16:52:27
@_slack_opencontainers_U01QQHWRDT3:matrix.orgPablo Rodríguez joined the room.17:04:42
8 Mar 2021
@_slack_opencontainers_U01L9HF6DQU:matrix.orgAvi Folks! Did anyone deploy harbor on EKS with alb as ingress. 20:42:55
@_slack_opencontainers_U01L9HF6DQU:matrix.orgAvi I am facing Health checks failure with target groups 20:44:01
@_slack_opencontainers_U01L9HF6DQU:matrix.orgAvi Any reference will be helpful Thanks! 20:44:21
@_slack_opencontainers_U01L9HF6DQU:matrix.orgAvi Deployed using helm as mentioned in :- https://ruzickap.github.io/k8s-harbor/part-04/#install-harbor-using-helm 20:44:59
@_slack_opencontainers_UGGPC8W85:matrix.orgSteve Lasker For those interested in the new OCI Artifact Reference Types, I'll be presenting tomorrow at RedHat Container Plumbing Days. Here's the deck 22:46:03
10 Mar 2021
@_slack_opencontainers_U01QS3H4QPP:matrix.orgCaleb Woodbine joined the room.22:22:23
@_slack_opencontainers_U01QS3H4QPP:matrix.orgCaleb Woodbine changed their profile picture.22:22:25
18 Mar 2021
@_slack_opencontainers_UGGPC8W85:matrix.orgSteve Lasker It's been a while since we posted an update here: We've been spending time working on how to support artifact enhancements, such as adding a Notary v2 signature, an SBoM, Nydus image, or other artifact reference. The premise is you can add new artifacts to a registry, that extend an existing artifact. You query on the original artifact, and use a {manifest}/{digest}/references api to find the linked references. (Naming still a bit debated) The PR is here: https://github.com/opencontainers/artifacts/pull/29 • To get directly to the Artifacts Manifest Overview: https://github.com/SteveLasker/artifacts/blob/oci-artifact-manifest/artifact-manifest.md • To get directly to the Artifact Manifest Spec: https://github.com/SteveLasker/artifacts/blob/oci-artifact-manifest/artifact-manifest-spec.md 15:55:31
@_slack_opencontainers_UGGPC8W85:matrix.orgSteve Lasker Thought folks might get a chuckle from this one: https://twitter.com/awakecoding/status/1372635693390905349 20:15:14
21 Mar 2021
@_slack_opencontainers_U01SP68UT4Y:matrix.orgDmitriy Labaznov joined the room.23:27:14
25 Mar 2021
@_slack_opencontainers_UGGPC8W85:matrix.orgSteve Lasker Hey artifact folks, For those that have been following the Notary v2 work, we've been approaching this in three areas of focus: 1. Definition of a Notary v2 Signature 2. Registry Persistence, Discovery and Retrieval 3. Key Management The intent is to support signing all content (OCI Artifacts) persisted in a registry, assuring the integrity from the point content enters a registry, as it's promoted within and across different registries, to the point of consumption. To support the Notary v2 goals of not changing the tag or digest of an artifact when signing, we've focused on linking artifacts, including signatures and other artifacts like SBoMs.  This provides a lot of power to store all sorts of content types, including graphs of objects. In the OCI working group, we've been discussing various approaches from changes to the existing OCI Image manifest (adding references to descriptors and clarifying use of the previously reserved descriptor data element) to defining a new oci.artifact.manifest spec that defines a subset of restrictions of the image.manifest, with a super set of capabilities, including manifest references. We've been debating the approach for how to leverage the registry infrastructure since the adoption of OCI Artifacts effort. The debates ranges from whether we should support anything other than container images, to how we support identifying what we realized was already happening. Users have long since been putting other content in a registry, they just made it look like a container image. Due to concerns around changing the schema of the oci.mage.manifest and breaking all the existing clients, the initial OCI Artifacts approach settled on using the image.manifest.config.mediaType to identify what the content represented.  This enabled users that were masking their content as an oci.image to clearly identify the usage. With addition of the ORAS libraries, an ever expanding set of new artifact types have surfaced, including Helm Chart, OPA, WASM. Singularity Image. We knew we needed more and this was just the beginning. We discussed adding a config to the oci.image.index and other various efforts to support additional artifact types, but kept bumping into constraints and realizing we were stretching the limit for what the manifests could support. We talked about refactoring the manifests which led to the new oci.artifact.manifest spec. However Justin Cormack has been noodling on the larger problem we've face with multi-arch manifests (image.index), artifact references, and versioning of the content, such as new gzip or stargz compression formats. Today, Justin provided a more generic, "one manifest to rule them all" approach. Generic Format for Registry Documents As registry operators, I'd suggest reading through this doc. Justin will get it posted somewhere for easier comments on specific lines. Will this be a big change? Yes. Is it worth it? If you're running distribution, you're more than likely supporting multiple artifact types. Whether it be Helm charts as OCI Artifacts, or running npm, nuget, maven and other package managers in your broader line of supported services. In Azure, we've proven we can support all package managers with the infrastructure of registries. We'd like to see this more generically possible, as we believe consuming public content should be promoted into a registry you control for the secure management for your systems. We believe the changes to support reference types, and identifying a versioned document will have far more reaching impact. In the short term, we believe the value of securing the integrity of content in a registry will justify the value for adopting a new artifact manifest. It will mean garbage collection is a bit harder as we'll have cross artifact references to ref-count. The value to also support SBoMs and other types will hopefully justify the investment. • At the minimum, please read Generic Format for Registry Documents • For more context of the scenarios, you can review: OCI Artifact Manifest overview Most of all, let us know what you think. We'll be reviewing this in more detail at the OCI Weekly meeting, next Wednesday. I'll see if we can get this added to our Tuesday CNCF Distribution meeting as well. 03:08:31
26 Mar 2021
@_slack_opencontainers_U01SK8TEV42:matrix.orgDan Lorenc joined the room.16:46:36
@_slack_opencontainers_U01SK8TEV42:matrix.orgDan Lorenc changed their profile picture.16:46:39
@_slack_opencontainers_U01SK8TEV42:matrix.orgDan Lorenc
In reply to@_slack_opencontainers_UGGPC8W85:matrix.org
Hey artifact folks, For those that have been following the Notary v2 work, we've been approaching this in three areas of focus: 1. Definition of a Notary v2 Signature 2. Registry Persistence, Discovery and Retrieval 3. Key Management The intent is to support signing all content (OCI Artifacts) persisted in a registry, assuring the integrity from the point content enters a registry, as it's promoted within and across different registries, to the point of consumption. To support the Notary v2 goals of not changing the tag or digest of an artifact when signing, we've focused on linking artifacts, including signatures and other artifacts like SBoMs.  This provides a lot of power to store all sorts of content types, including graphs of objects. In the OCI working group, we've been discussing various approaches from changes to the existing OCI Image manifest (adding references to descriptors and clarifying use of the previously reserved descriptor data element) to defining a new oci.artifact.manifest spec that defines a subset of restrictions of the image.manifest, with a super set of capabilities, including manifest references. We've been debating the approach for how to leverage the registry infrastructure since the adoption of OCI Artifacts effort. The debates ranges from whether we should support anything other than container images, to how we support identifying what we realized was already happening. Users have long since been putting other content in a registry, they just made it look like a container image. Due to concerns around changing the schema of the oci.mage.manifest and breaking all the existing clients, the initial OCI Artifacts approach settled on using the image.manifest.config.mediaType to identify what the content represented.  This enabled users that were masking their content as an oci.image to clearly identify the usage. With addition of the ORAS libraries, an ever expanding set of new artifact types have surfaced, including Helm Chart, OPA, WASM. Singularity Image. We knew we needed more and this was just the beginning. We discussed adding a config to the oci.image.index and other various efforts to support additional artifact types, but kept bumping into constraints and realizing we were stretching the limit for what the manifests could support. We talked about refactoring the manifests which led to the new oci.artifact.manifest spec. However Justin Cormack has been noodling on the larger problem we've face with multi-arch manifests (image.index), artifact references, and versioning of the content, such as new gzip or stargz compression formats. Today, Justin provided a more generic, "one manifest to rule them all" approach. Generic Format for Registry Documents As registry operators, I'd suggest reading through this doc. Justin will get it posted somewhere for easier comments on specific lines. Will this be a big change? Yes. Is it worth it? If you're running distribution, you're more than likely supporting multiple artifact types. Whether it be Helm charts as OCI Artifacts, or running npm, nuget, maven and other package managers in your broader line of supported services. In Azure, we've proven we can support all package managers with the infrastructure of registries. We'd like to see this more generically possible, as we believe consuming public content should be promoted into a registry you control for the secure management for your systems. We believe the changes to support reference types, and identifying a versioned document will have far more reaching impact. In the short term, we believe the value of securing the integrity of content in a registry will justify the value for adopting a new artifact manifest. It will mean garbage collection is a bit harder as we'll have cross artifact references to ref-count. The value to also support SBoMs and other types will hopefully justify the investment. • At the minimum, please read Generic Format for Registry Documents • For more context of the scenarios, you can review: OCI Artifact Manifest overview Most of all, let us know what you think. We'll be reviewing this in more detail at the OCI Weekly meeting, next Wednesday. I'll see if we can get this added to our Tuesday CNCF Distribution meeting as well.
A bunch of actionable items were preempted last Wednesday, I'd like to suggest we make some time to cover these as well before coming back to this doc, out of fairness and respect for everyones time.
16:47:35
@_slack_opencontainers_U01SK8TEV42:matrix.orgDan Lorenc
In reply to@_slack_opencontainers_U01SK8TEV42:matrix.org
A bunch of actionable items were preempted last Wednesday, I'd like to suggest we make some time to cover these as well before coming back to this doc, out of fairness and respect for everyones time.
In particular the questions about whether or not the image spec is "locked"
16:47:51
@_slack_opencontainers_U01S9E83VJ9:matrix.orgJason Hall joined the room.16:51:30
@_slack_opencontainers_UGGPC8W85:matrix.orgSteve Lasker
In reply to@_slack_opencontainers_U01SK8TEV42:matrix.org
In particular the questions about whether or not the image spec is "locked"
This discussion was covered at: https://opencontainers.slack.com/archives/C0LQVA03W/p1616790523047700
21:41:34
2 Apr 2021
@_slack_opencontainers_U01T08CPGTY:matrix.orgDaniel Shubin joined the room.23:05:09
9 Apr 2021
@_slack_opencontainers_U01TFAY8S6T:matrix.orgNick Coult joined the room.22:13:03
14 Apr 2021
@drrenardscd:matrix.org@drrenardscd:matrix.org joined the room.08:06:03
@drrenardscd:matrix.org@drrenardscd:matrix.org joined the room.09:44:16
@drrenardscd:matrix.org@drrenardscd:matrix.org left the room.09:46:11
15 Apr 2021
@_slack_opencontainers_U01T35R6JDD:matrix.orgGreesje joined the room.12:59:11
19 Apr 2021
@vbatts:matrix.orgvbatts changed their profile picture.18:13:28
@_slack_opencontainers_U3WGCSCV7:matrix.orgvbatts changed their profile picture.19:28:31
24 Apr 2021
@_slack_opencontainers_U01UWGVDSAK:matrix.orgBrandon Mitchell joined the room.00:13:47
29 Apr 2021
@_slack_opencontainers_U01UWGVDSAK:matrix.orgBrandon Mitchell changed their profile picture.09:13:23
12 May 2021
@_slack_opencontainers_UJE39AK3Q:matrix.orgMichael Brown changed their profile picture.23:08:21

There are no newer messages yet.


Back to Room List