[nydusify] Bump acceleration-service to build manifests with artifactType

Nydus images built using `nydusify convert --merge-platform` will now use the `artifactType` field in the index to identify the nydus manifest. This replaces the former `os.features: "nydus.remoteimage.v1"` because using it was proving to be difficult on some registries like ECR which do not accept this field.
The SOCI snapshotter actually also use this field so if any registry doesn't support `artifactType` in the future, they will have more pressure to support this.

Signed-off-by: Baptiste Girard-Carrabin <[email protected]>

Author: Fricounet

contrib/nydusify/examples/manifest/index.json

@@ -16,11 +16,9 @@
       "size": 1367,
       "platform": {
         "architecture": "amd64",
-        "os": "linux",
-        "os.features": [
-          "nydus.remoteimage.v1"
-        ]
-      }
+        "os": "linux"
+      },
+      "artifactType": "application/vnd.nydus.image.manifest.v1+json"
     }
   ]
 }

contrib/nydusify/go.mod

@@ -20,7 +20,7 @@ require (
 	github.com/distribution/reference v0.6.0
 	github.com/docker/cli v28.1.1+incompatible
 	github.com/dustin/go-humanize v1.0.1
-	github.com/goharbor/acceleration-service v0.2.18
+	github.com/goharbor/acceleration-service v0.2.19
 	github.com/google/uuid v1.6.0
 	github.com/hashicorp/go-hclog v1.6.2
 	github.com/hashicorp/go-plugin v1.6.0

contrib/nydusify/go.sum

@@ -125,8 +125,8 @@ github.com/go-logr/stdr v1.2.2 h1:hSWxHoqTgW2S2qGc0LTAI563KZ5YKYRhT3MFKZMbjag=
 github.com/go-logr/stdr v1.2.2/go.mod h1:mMo/vtBO5dYbehREoey6XUKy/eSumjCCveDpRre4VKE=
 github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q=
 github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q=
-github.com/goharbor/acceleration-service v0.2.18 h1:xI1U/2AoH+1m5uV2QmwHPBPxxBTTPr0m7QvbU0HAQoY=
-github.com/goharbor/acceleration-service v0.2.18/go.mod h1:REj3y6AJjrOZbH0K904W/7QYojkiFECdLomJCyXOgxk=
+github.com/goharbor/acceleration-service v0.2.19 h1:pZ1iBaUUAZiQReqWHvYMM9f1M/HB2kLeXKmgDdMyCdk=
+github.com/goharbor/acceleration-service v0.2.19/go.mod h1:REj3y6AJjrOZbH0K904W/7QYojkiFECdLomJCyXOgxk=
 github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q=
 github.com/golang/groupcache v0.0.0-20200121045136-8c9f03a8e57e/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
 github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da h1:oI5xCqsCo564l8iNU+DwB5epxmsaqB+rhGL0m5jtYqE=

docs/nydus-design.md

@@ -68,7 +68,7 @@ Rafs is a filesystem image containing a separated metadata blob and several data
 |            |           |                                                 |
 +------------+-----------+-------------------------------------------------+
 ```
-   
+
 ##    3. Integrity Validation
 ### 3.1 Metadata Integrity Validation
 Firstly, Nydus does basic verification of metadata values, looking for values that are in range (and hence not detected by automated verification checks) but are not correct.
@@ -185,9 +185,9 @@ pub struct OndiskInodeWrapper<'a> {
     pub inode: &'a OndiskInode,
 }
 ```
- 
+
 The OndiskInode struct size is padded to 128 bytes.
-   
+
 * If it's a directory, all its children are indexed contiguously in `inode table`, and `i_child_index` is the index of the first child and `i_child_count` is the amount of its children.
 * If it's a file, `i_child_index` is not used.
 *`i_name_size` is the length of its name.
@@ -248,7 +248,7 @@ pub struct OndiskXAttrs {
 }
 ```
 
-A list of `OndiskChunkInfo` is also stored after xattr if the inode contains file data.  Each chunk info tells us where to find data in blob file, it contains 
+A list of `OndiskChunkInfo` is also stored after xattr if the inode contains file data.  Each chunk info tells us where to find data in blob file, it contains
 - the hash value `block_id` calculated from the chunk data,
 - the blob file it belongs to,
 - whether the chunk is compressed,
@@ -323,7 +323,7 @@ pub struct OndiskBlobTable {
 Nydus manifest is designed to be fully compatible with OCI image spec and distribution spec by adding an extra manifest file to store the pointers of nydus bootstrap (i.e. metadata) and blobfile (i.e. data).
 
 ## 1. Image Index
-A typical image index enabling nydus points to two manifest files, one is the traditional OCI v1 image manifest, the other is the nydus manifest that takes advantage of `platform` and puts `os.features: ["nydus.remoteimage.v1"]` field under `platform`.
+A typical image index enabling nydus points to two manifest files, one is the traditional OCI v1 image manifest, the other is the nydus manifest that takes advantage of `artifactType` and puts `application/vnd.nydus.image.manifest.v1+json` as a value to identify the nydus image.
 
 ```json
 {
@@ -345,10 +345,8 @@ A typical image index enabling nydus points to two manifest files, one is the tr
       "platform": {
         "architecture": "amd64",
         "os": "linux",
-        "os.features": [
-          "nydus.remoteimage.v1"
-        ]
-      }
+      },
+      "artifactType": "application/vnd.nydus.image.manifest.v1+json"
     }
   ]
 }