Adds model card feature procedure (#1240)

stevsmit · Steven Smith · web-flow · commit 4a7f5dd3e28b · 2025-03-21T07:11:08.000-04:00
Co-authored-by: Steven Smith &lt;stevsmit@stevsmit-thinkpadt14gen4.remote.csb&gt;
diff --git a/images/modelcard.png b/images/modelcard.png
diff --git a/modules/config-fields-modelcard-rendering.adoc b/modules/config-fields-modelcard-rendering.adoc
@@ -6,8 +6,8 @@ The following configuration fields have been added to support model card renderi
 |===
 | Field | Type | Description 
 
-|*FEATURE_UI_MODELCARD* |Boolean | Enables *Modelcard* image tab in UI. Defaults to `true`.
-|*UI_MODELCARD_ARTIFACT_TYPE* | String | Defines the modelcard artifact type.
+|*FEATURE_UI_MODELCARD* |Boolean | Enables *Model Card* image tab in UI. Defaults to `true`.
+|*UI_MODELCARD_ARTIFACT_TYPE* | String | Defines the model card artifact type.
 |*UI_MODELCARD_ANNOTATION* |Object | This optional field  defines the layer annotation of the model card stored in an OCI image.
 |*UI_MODELCARD_LAYER_ANNOTATION* |Object | This optional field defines the layer annotation of the model card stored in an OCI image.
 |===
@@ -22,7 +22,7 @@ UI_MODELCARD_ANNOTATION: <3>
 UI_MODELCARD_LAYER_ANNOTATION: <4>
   org.opencontainers.image.title: README.md
 ----
-<1> Enables the ModelCard image tab in the UI.
+<1> Enables the *Model Card* image tab in the UI.
 <2> Defines the model card artifact type. In this example, the artifact type is `application/x-mlmodel`.
 <3> Optional. If an image does not have an `artifactType` defined, this field is checked at the manifest level. If a matching annotation is found, the system then searches for a layer with an annotation matching `UI_MODELCARD_LAYER_ANNOTATION`.
 <4> Optional. If an image has an `artifactType` defined and multiple layers, this field is used to locate the specific layer containing the model card.
diff --git a/modules/config-updates-314.adoc b/modules/config-updates-314.adoc
@@ -12,8 +12,8 @@ The following configuration fields have been added to support model card renderi
 |===
 | Field | Type | Description 
 
-|*FEATURE_UI_MODELCARD* |Boolean | Enables *Modelcard* image tab in UI. Defaults to `true`.
-|*UI_MODELCARD_ARTIFACT_TYPE* | String | Defines the modelcard artifact type.
+|*FEATURE_UI_MODELCARD* |Boolean | Enables *Model card* image tab in UI. Defaults to `true`.
+|*UI_MODELCARD_ARTIFACT_TYPE* | String | Defines the model card artifact type.
 |*UI_MODELCARD_ANNOTATION* |Object | This optional field defines the layer annotation of the model card stored in an OCI image.
 |*UI_MODELCARD_LAYER_ANNOTATION* |Object | This optional field defines the layer annotation of the model card stored in an OCI image.
 |===
@@ -28,7 +28,7 @@ UI_MODELCARD_ANNOTATION: <3>
 UI_MODELCARD_LAYER_ANNOTATION: <4>
   org.opencontainers.image.title: README.md
 ----
-<1> Enables the ModelCard image tab in the UI.
+<1> Enables the *Model Card* image tab in the UI.
 <2> Defines the model card artifact type. In this example, the artifact type is `application/x-mlmodel`.
 <3> Optional. If an image does not have an `artifactType` defined, this field is checked at the manifest level. If a matching annotation is found, the system then searches for a layer with an annotation matching `UI_MODELCARD_LAYER_ANNOTATION`.
 <4> Optional. If an image has an `artifactType` defined and multiple layers, this field is used to locate the specific layer containing the model card.
diff --git a/modules/creating-an-image-repository-via-skopeo-copy.adoc b/modules/creating-an-image-repository-via-skopeo-copy.adoc
@@ -0,0 +1,72 @@
+ 
+// module included in the following assemblies:
+
+// * use_quay/master.adoc
+// * quay_io/master.adoc
+
+:_content-type: CONCEPT
+
+[id="creating-an-image-repository-via-skopeo-copy"]
+= Creating a repository by using Skopeo
+
+In some cases, the `podman` CLI tool is unable to pull certain artifact types, for example, `application/x-mlmodel`. Attempting to use `podman pull` with this artifact type results in the following error:
+
+[source,terminal]
+----
+Error: parsing image configuration: unsupported image-specific operation on artifact with type "application/x-mlmodel"
+----
+
+As an alternative, you can use `skopeo copy` to copy an artifact from one location to your {productname} repository.
+
+.Prerequisites
+
+* You have installed the `skopeo` CLI.
+* You have logged in to a source registry (in this example, `\registry.redhat.io`) and have a valid authentication file (`~/.docker/config.json`). Alternatively, you can provide credentials by using the `--src-username` and `--src-password` parameters when running a command with the `skopeo` CLI.
+* You have logged in to your {productname} repository.
+
+.Procedure
+
+* Use the `skopeo copy` command on an artifact to copy the artifact to your {productname} repository. For example:
++
+[source,terminal]
+----
+$ sudo skopeo copy --dest-tls-verify=false --all \ <1> <2>
+  --src-username <source_username> --src-password <source_password> \ <3>
+  --src-authfile ~/.docker/config.json \ <4>
+  --dest-username <username> --dest-password <password> \ <5>
+  docker://registry.redhat.io/rhelai1/granite-8b-code-instruct:1.4-1739210683 \ <6>
+  docker://quay-server.example.com/<namespace>/granite-8b-code-instruct:latest <7>
+----
+<1> Optional. `--dest-tls-verify=false` disables SSL/TLS verification for the destination registry. 
+<2> Optional. The `--all` flag optionally copies all image manifests, including multi-architecture images.
+<3> Optional. If you are not logged into a registry, you can pass in the source registry credentials with these parameters.
+<4> Optional. The path to your Docker authentication file. Typically located at `~/.docker/config.json`.
+<5> Your {productname} registry username and password.
+<6>  The source image or artifact from the Red{nbsp}Hat container registry. Ensure that you are logged in to the registry and that you can pull the image.
+<7> The URL of your {productname} repository appended with a namespace and the name of the image. 
++
+.Example output
++
+[source,terminal]
+----
+Getting image source signatures
+Checking if image destination supports signatures
+Copying blob 9538fa2b8ad9 done   | 
+Copying blob 491ae95f59a2 done   | 
+Copying blob 01196d075d77 done   | 
+Copying blob e53a4633c992 done   | 
+Copying blob c266e9cfa731 done   | 
+Copying blob dae0e701d9b2 done   | 
+Copying blob 1e227a2c78d8 done   | 
+Copying blob 94ff9338861b done   | 
+Copying blob 2f2bba45146f done   | 
+Copying blob d3b4df07a0ce done   | 
+Copying blob f533a8dbb852 done   | 
+Copying config 44136fa355 done   | 
+Writing manifest to image destination
+Storing signatures
+----
+
+.Next steps
+
+* After you have pushed a machine learning artifact to your {productname} repository, you can link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/use_red_hat_quay/index#viewing-and-modifying-tags[View tag information by using the UI] or link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/use_red_hat_quay/index#viewing-model-card-information[View model card information by using the UI].
diff --git a/modules/proc_use-quay-create-repo.adoc b/modules/proc_use-quay-create-repo.adoc
@@ -35,7 +35,12 @@ ifeval::["{context}" == "quay-io"]
 There are two ways to create a repository in {quayio}: by pushing an image with the relevant `podman` command, or by using the {quayio} UI. You can also use the UI to delete a repository.
 endif::[]
 ifeval::["{context}" == "use-quay"]
-There are three ways to create a repository in {productname}: by pushing an image with the relevant `podman` command, by using the {productname} UI, or by using the {productname} API. Similarly, repositories can be deleted by using the UI or the proper API endpoint.
+There are multiple ways to create a repository in {productname}. The following options are available depending on your use case:
+
+* You can push an image with the relevant `podman` or `docker` command.
+* You can use the {productname} UI.
+* You can use the {productname} API.
+* For OCI artifacts, for example, a large-language model (LLM) or machine learning application, you can use `skopeo` or `oras` to copy the artifact to your repository.
 endif::[]
 
 ifeval::["{context}" == "quay-io"]
diff --git a/modules/rn_3_14_0.adoc b/modules/rn_3_14_0.adoc
@@ -28,22 +28,24 @@ The following documentation changes have been made with the {productname} 3.14 r
 The following updates have been made to {productname}.
 
 [id="model-card-rendering"]
-=== User-interface modelcard rendering
+=== Model card rendering on the v2 UI
 
-With the release of {productname} 3.14, modelcard rendering has been introduced to the v2 UI for machine learning models. When a manifest has a certain annotation and a modelcard stored as its layer, a *ModelCard* tab is displayed on the tag's information page. The information provided on the *ModelCard* page provides users with comprehensive insights into each model, and can help enhance a user's understanding of models stored within your registry.
+With the release of {productname} 3.14, the v2 UI now renders model card information for machine learning models that include a model card. When a manifest has a certain annotation (for example, `application/x-mlmodel`) and a model card stored as a layer in the manifest, a *Model Card* tab is displayed on the tag's information page. The information on the *Model Card* page provides users with comprehensive insights into each model, and can help enhance a user's understanding of models stored within their registry.
 
 [NOTE]
 ====
-Modelcard rendering is only available on the {productname} v2 UI.
+The *Model Card* rendering page is only available on the {productname} v2 UI.
 ====
 
-For more information, see. . .
+To view model card information, {productname} users or administrators must push an artifact to a repository. The artifact must have have an accompanying model card. This information renders under *Repository* -> *<tag_name>* -> *Model Card*.
+
+For more information, see link:https://docs.redhat.com/en/documentation/red_hat_quay/3/html-single/use_red_hat_quay/index#viewing-model-card-information[Viewing model card information by using the v2 UI].
 
 [id="tag-expiration-enhancement"]
 === Tag expiration enhancement
 
 Previously, when configuring tag expiration for {productname}, the `yearly` option was unavailable on the {productname} v2 UI. With this update, users can now configure default tag expiration to occur yearly on the {productname} v2 UI. This can be set by using the {productname} UI or in your `config.yaml` file. For example:
-+
+
 [source,yaml]
 ----
 DEFAULT_TAG_EXPIRATION: 1y
@@ -54,7 +56,7 @@ TAG_EXPIRATION_OPTIONS:
 [id="new-quay-config-fields-314"]
 == {productname} configuration fields updates and changes
 
-The following configuration fields have been added to {productname} {producty}.
+The following configuration fields have been added to {productname} 3.14.
 
 [id="model-card-rendering-configuration-field"]
 === Model card rendering configuration fields
@@ -70,19 +72,20 @@ The following configuration fields have been added for the model card rendering
 |*UI_MODELCARD_LAYER_ANNOTATION* |Object | This optional field defines the layer annotation of the model card stored in an OCI image.
 |===
 
-To enable model card rendering on the {productname} v2 UI, you must set `FEATURE_UI_MODELCARD: true` and `UI_MODELCARD_ARTIFACT_TYPE` in your `config.yaml` file. For example:
+These configuration fields are enabled and set by default in your `config.yaml` file:
 
 .Example model card YAML
 [source,yaml]
 ----
-FEATURE_UI_MODELCARD: true <1>
-UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel <2>
-UI_MODELCARD_ANNOTATION: <3>
+FEATURE_UI_MODELCARD: true
+UI_MODELCARD_ARTIFACT_TYPE: application/x-mlmodel
+UI_MODELCARD_ANNOTATION:
   org.opencontainers.image.description: "Model card metadata"
-UI_MODELCARD_LAYER_ANNOTATION: <4>
+UI_MODELCARD_LAYER_ANNOTATION:
   org.opencontainers.image.title: README.md
 ----
-For more information about this feature, see. . .
+
+For more information, see link:https://docs.redhat.com/en/documentation/red_hat_quay/3/html-single/use_red_hat_quay/index#viewing-model-card-information[Viewing model card information by using the v2 UI].
 
 [id="ignore-unknown-mediatype-removal"]
 === IGNORE_UNKNOWN_MEDIATYPES configuration field removal
diff --git a/modules/using-v2-ui.adoc b/modules/using-v2-ui.adoc
@@ -375,7 +375,7 @@ Use the following procedure to alter your organization settings using the v2 UI.
 [id="tag-overview-v2-ui"]
 === Viewing image tag information using the v2 UI
 
-Use the following procedure to view image tag information using the v2 UI. 
+Use the following procedure to view image tag information by using the v2 UI. 
 
 .Procedure 
 
diff --git a/modules/viewing-and-modifying-tags.adoc b/modules/viewing-and-modifying-tags.adoc
@@ -1,12 +1,12 @@
-:_content-type: CONCEPT
+:_content-type: PROCEDURE
 [id="viewing-and-modifying-tags"]
 = Viewing image tag information by using the UI
  
 Use the following procedure to view image tag information using the v2 UI.
 
 .Prerequisites
 
-* You have pushed an image tag to a repository.
+* You have pushed an image tag to a repository. 
 
 .Procedure 
  
@@ -28,6 +28,6 @@ Use the following procedure to view image tag information using the v2 UI.
 
 . Click *Security Report* to view the tag's vulnerabilities. You can expand an advisory column to open up CVE data. 
 
-. Click *Packages* to view the tag's packages. 
+. Click *Packages* to view the tag's packages.
 
 . Click the name of the repository to return to the *Tags* page.
diff --git a/modules/viewing-model-card-information.adoc b/modules/viewing-model-card-information.adoc
@@ -1,7 +1,8 @@
+:_content-type: PROCEDURE
 [id="viewing-model-card-information"]
 = Viewing model card information by using the UI
  
-Model card information can be viewed on the v2 UI. Model cards are essentially markdown (`.md`) files with additional metadata that provide information about a machine learning application. To view model card information, a manifest must have an annotation that is defined in your `config.yaml` file (for example, `application/x-mlmodel`) and include a model card stored as a layer in the manifest. When these conditions are met, a *ModelCard* tab appears on the *Details* page of a tag.
+Model card information can be viewed on the v2 UI. Model cards are essentially markdown (`.md`) files with additional metadata that provide information about a machine learning application. To view model card information, a manifest must have an annotation that is defined in your `config.yaml` file (for example, `application/x-mlmodel`) and include a model card stored as a layer in the manifest. When these conditions are met, a *Model Card* tab appears on the *Details* page of a tag.
 
 * You have pushed an artifact of that annotation type, and it includes a model card (`.md`) file.
 
@@ -19,7 +20,7 @@ UI_MODELCARD_ANNOTATION: <3>
 UI_MODELCARD_LAYER_ANNOTATION: <4>
   org.opencontainers.image.title: README.md
 ----
-<1> Enables the ModelCard image tab in the UI.
+<1> Enables the Model Card image tab in the UI.
 <2> Defines the model card artifact type. In this example, the artifact type is `application/x-mlmodel`.
 <3> Optional. If an image does not have an `artifactType` defined, this field is checked at the manifest level. If a matching annotation is found, the system then searches for a layer with an annotation matching `UI_MODELCARD_LAYER_ANNOTATION`.
 <4> Optional. If an image has an `artifactType` defined and multiple layers, this field is used to locate the specific layer containing the model card.
diff --git a/use_quay/master.adoc b/use_quay/master.adoc
@@ -38,6 +38,7 @@ include::modules/org-delete-api.adoc[leveloffset=+2]
 include::modules/proc_use-quay-create-repo.adoc[leveloffset=+1]
 include::modules/creating-an-image-repository-via-the-ui.adoc[leveloffset=+2]
 include::modules/creating-an-image-repository-via-docker.adoc[leveloffset=+2]
+include::modules/creating-an-image-repository-via-skopeo-copy.adoc[leveloffset=+2]
 include::modules/creating-an-image-repository-via-the-api.adoc[leveloffset=+2]
 include::modules/deleting-an-image-repository-via-ui.adoc[leveloffset=+2]
 include::modules/deleting-an-image-repository-via-the-api.adoc[leveloffset=+2]
@@ -79,6 +80,7 @@ include::modules/adjust-access-user-repo-api.adoc[leveloffset=+2]
 //image tags overview
 include::modules/image-tags-overview.adoc[leveloffset=+1]
 include::modules/viewing-and-modifying-tags.adoc[leveloffset=+2]
+include::modules/viewing-model-card-information.adoc[leveloffset=+3]
 include::modules/viewing-tags-api.adoc[leveloffset=+2]
 include::modules/adding-a-new-tag-to-image.adoc[leveloffset=+2]
 include::modules/adding-a-new-tag-to-image-api.adoc[leveloffset=+2]
@@ -114,7 +116,7 @@ include::modules/creating-notifications-api.adoc[leveloffset=+2]
 include::modules/repository-events.adoc[leveloffset=+2]
 
 //docker files 
-include::modules/proc_use-quay-build-workers-dockerfiles.adoc[leveloffset=+1]
+//include::modules/proc_use-quay-build-workers-dockerfiles.adoc[leveloffset=+1]
 //include::modules/proc_use-quay-build-dockerfiles.adoc[leveloffset=+1]
 
 //custom trigger
@@ -145,7 +147,7 @@ include::modules/proxy-cache-procedure.adoc[leveloffset=+2]
 include::modules/proxy-cache-leveraging-storage-quota-limits.adoc[leveloffset=+2]
 
 // Virtual builders
-include::modules/build-enhancements.adoc[leveloffset=+1]
+//include::modules/build-enhancements.adoc[leveloffset=+1]
 //include::modules/build-enhanced-arch.adoc[leveloffset=+2]
 //include::modules/build-limitations.adoc[leveloffset=+2]
 //include::modules/builders-virtual-environment.adoc[leveloffset=+2]
