add nydus image artifact

[liubogithub]

Artifact manifest is a nice way to offer the ability of enhancing
registry as well as applying minimum modifications to client tools.

Nydus image is an alternative representation of container image,
providing benefits like making starting containers as fast as
possible.

We'd like to have nydus image persist as a new artifact like helm
charts.

Signed-off-by: Peng Tao <tao.peng@linux.alibaba.com>
Signed-off-by: Liu Bo bo.liu@linux.alibaba.com

[SteveLasker]

Peng, Liu, can you update to use the [manifests] collection as linked artifacts? Or, were these truly loose references as the original proposal outlined?

[liubogithub]

@SteveLasker
Sure, I'll update it accordingly, thanks.

Peng, Liu, can you update to use the [manifests] collection as linked artifacts? Or, were these truly loose references as the original proposal outlined?

From our perspective, nydus image is allowed to be stored and used without its ociv1 image, so I assume that "references" fits better in this case.

[liubogithub]

@bergwolf

[SteveLasker]

Hi @liubogithub,
The original oci.artifact.manifest had two collections.

• One for links to existing [manifests], to add additional data to an artifact, like signatures, SBoMs, etc. These were "upward" references, meaning signature points up the tree to the artifact it's signing.
• Another for loose [references] to existing artifacts. These were "downward" references. Meaning, a Helm chart would reference an image. A CNAB would reference an image and a helm chart.

PR 27 became too controversial and was distracting from the linked lists for Notary v2 and SBoM, so we decided to put loose [references] on hold.

As a result, PR 29 focuses on just [manifests]

What I'm not fully understanding is how Nydus works. Does a Nydus artifact work by adding a collection of blobs that provide an alternative layer persistence? Meaning, the original wordpress:5 image is still in the registry. And, there's a nydus artifact in the registry that says, here are some nydus layers for that same image. A nydus client would find this through the new manifest list/links API.

Or, said another way. When the wordpress:5 image is deleted, should the nydus artifact be deleted?

In the loose [reference] case, deleting a helm chart does not mean the images are deleted.
In the [manifests] collection, deleting the wordpress:5 image would always delete any Notary v2 signatures or SBoMs associated with the wordpress:5 image.

If you want to do a PR against this latest [manifests] version, I can certainly take than in. If you want to just provide a sample a Nydus oci.artifact.manifest, I can paste it in as well.

I realize this may be a bit confusing. I'm also presenting at the RedHat Container Plumbing Days and will be spending next week clarifying the oci.artifact.manifest PR with spec information.

[bergwolf]

Hi @SteveLasker

Does a Nydus artifact work by adding a collection of blobs that provide an alternative layer persistence? Meaning, the original wordpress:5 image is still in the registry.

Yes, that is how we expect Nydus artifact to work. The original wordpress:5 image can even in a different repository if the spec allows it.

And, there's a nydus artifact in the registry that says, here are some nydus layers for that same image. A nydus client would find this through the new manifest list/links API.

Yes, nydus can make use of the list/links API. A nydus client can query linked manifest of wordpress:5 and find out nydus manifest from the returned result.

When the wordpress:5 image is deleted, should the nydus artifact be deleted?

It depends on how a registry plans to present its nydus capability. If nydus is provided automatically by a registry, the nydus artifact should be deleted when wordpress:5 is deleted. For example, we are working with the Harbor project to make nydus a builtin capability and an nydus image will be created automatically when a user pushes an OCI image to the Harbor repository. Such nydus image is linked to the original OCI image and shares the same life cycle. It will be deleted when the original wordpress:5 image is deleted.

However, if nydus capability is exposed to users directly for example if a registry allows users to push nydus image directly, it should not be deleted when wordpress:5 is deleted. In such case, nydus artifact can have a loose [reference] relation to the original OCI image.

So it seems that nydus can use both the [manifests] and the loose [reference] collections. We can first post a PR against the latest [manifests] version, and when the loose [reference] collection is proposed, we can add how nydus artifact looks like in the [reference] form there as well. What do you think?

[SteveLasker]

Might I suggest you experiment a bit a reference implementation?
Please see: ORAS: OCI Artifact Manifest (Experimental)
It implements the oci.artifact.manifest PR.
We're seeing this as the first step towards the WIP generic object spec #37. If you could provide feedback on the oci.artifact.manifest PR #29 that will help us figure out what changes might be needed for the generic object spec

[liubogithub]

Might I suggest you experiment a bit a reference implementation?
Please see: ORAS: OCI Artifact Manifest (Experimental)
It implements the oci.artifact.manifest PR.
We're seeing this as the first step towards the WIP generic object spec #37. If you could provide feedback on the oci.artifact.manifest PR #29 that will help us figure out what changes might be needed for the generic object spec

Sure, will have a look.

Btw, I found an error in
https://github.com/deislabs/oras/blob/prototype-2/docs/artifact-manifest.md#discovering-artifacts-with-artifacttype-filtering

It is "signature" instead of SBom

Push the SBoM, referencing the hello-world:latest image:

oras push localhost:5000/hello-world \
    --artifact-type application/x.example.signature.v0 \
    --artifact-reference localhost:5000/hello-world:latest \
    signature.json:application/tar

[SteveLasker]

Thanks @liubogithub for the copy/paste error. I've pushed the fix.